Re: [PATCH] drm/amd/display: Expose support for DRM_FORMAT_RGB565
On 2019-04-15 10:27 a.m., Nicholas Kazlauskas wrote:
> DC and DM already support DRM_FORMAT_RGB565, it's just missing from the
> list of valid formats.
>
> Cc: Harry Wentland
> Cc: Leo Li
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 44a8bf8ead79..a5cacf846e1b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4274,6 +4274,7 @@ static const uint32_t rgb_formats[] = {
> DRM_FORMAT_ABGR2101010,
> DRM_FORMAT_XBGR,
> DRM_FORMAT_ABGR,
> + DRM_FORMAT_RGB565,
> };
>
> static const uint32_t overlay_formats[] = {
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Only allow VRR when vrefresh is within supported range
On 2019-03-21 11:53 a.m., Nicholas Kazlauskas wrote:
> [Why]
> Black screens or artifacting can occur when enabling FreeSync outside
> of the supported range of the monitor. This can happen since the
> supported range isn't always the min/max vrefresh range available for
> the monitor.
>
> [How]
> There was previously a fix that prevented this from happening in the
> low range but it didn't cover the upper range. Expand the condition
> to include both.
>
> Cc: Sun peng Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 01a46119512b..5b7a85e28fab 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5551,9 +5551,11 @@ static void get_freesync_config_for_crtc(
> struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(new_con_state->base.connector);
> struct drm_display_mode *mode = _crtc_state->base.mode;
> + int vrefresh = drm_mode_vrefresh(mode);
>
> new_crtc_state->vrr_supported = new_con_state->freesync_capable &&
> - aconnector->min_vfreq <= drm_mode_vrefresh(mode);
> + vrefresh >= aconnector->min_vfreq &&
> + vrefresh <= aconnector->max_vfreq;
>
> if (new_crtc_state->vrr_supported) {
> new_crtc_state->stream->ignore_msa_timing_param = true;
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.
On 2019-03-21 5:39 a.m., Mario Kleiner wrote: > On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas > wrote: >> >> On 3/20/19 3:51 AM, Mario Kleiner wrote: >>> Ok, fixed all the style issues and ran checkpatch over the patches. Thanks. >>> >>> On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nicholas >>> wrote: On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote: > On 3/18/19 1:19 PM, Mario Kleiner wrote: ...snip... >> diff --git >> a/drivers/gpu/drm/amd/display/dc/irq/dcn10/irq_service_dcn10.c >> b/drivers/gpu/drm/amd/display/dc/irq/dcn10/irq_service_dcn10.c >> index e04ae49..10ac6de 100644 >> --- a/drivers/gpu/drm/amd/display/dc/irq/dcn10/irq_service_dcn10.c >> +++ b/drivers/gpu/drm/amd/display/dc/irq/dcn10/irq_service_dcn10.c >> @@ -56,6 +56,18 @@ enum dc_irq_source to_dal_irq_source_dcn10( >> return DC_IRQ_SOURCE_VBLANK5; >> case DCN_1_0__SRCID__DC_D6_OTG_VSTARTUP: >> return DC_IRQ_SOURCE_VBLANK6; >> +case DCN_1_0__SRCID__OTG0_IHC_V_UPDATE_NO_LOCK_INTERRUPT: >> +return DC_IRQ_SOURCE_VUPDATE1; >> +case DCN_1_0__SRCID__OTG1_IHC_V_UPDATE_NO_LOCK_INTERRUPT: >> +return DC_IRQ_SOURCE_VUPDATE2; >> +case DCN_1_0__SRCID__OTG2_IHC_V_UPDATE_NO_LOCK_INTERRUPT: >> +return DC_IRQ_SOURCE_VUPDATE3; >> +case DCN_1_0__SRCID__OTG3_IHC_V_UPDATE_NO_LOCK_INTERRUPT: >> +return DC_IRQ_SOURCE_VUPDATE4; >> +case DCN_1_0__SRCID__OTG4_IHC_V_UPDATE_NO_LOCK_INTERRUPT: >> +return DC_IRQ_SOURCE_VUPDATE5; >> +case DCN_1_0__SRCID__OTG5_IHC_V_UPDATE_NO_LOCK_INTERRUPT: >> +return DC_IRQ_SOURCE_VUPDATE6; I'm not sure we necessarily want to reuse the same DC_IRQ_SOURCE_VUPDATE1...6 definitions here again when it's really V_UPDATE_NO_LOCK. >>> >>> Hm. The problem is that if we use different ones for DCE and DCN we >>> need special-case handling in amdgpu_dm.c, e.g., in >>> amdgpu_dm_set_vupdate_irq_state() and dm_set_vupdate_irq() to detect >>> if it is caling DCE or DCN (how to detect this?) to select different >>> irq sources IRQ_TYPE_VUPDATE vs IRQ_TYPE_VUPDATE_NO_LOCK and such? >>> And definitions like "struct amdgpu_irq_src vupdate_irq;" should then >>> also exist twice as vupdate_irq and vupdate_irq_no_lock for correct >>> naming? >>> >>> Or we'd name the IRQ source and all relevant data structures and >>> functions something like DC_IRQ_SOURCE_VBLANK_END1..6 to describe what >>> it signals instead of to what it corresponds in hardware? That would >>> be what was done with the regular DC_IRQ_SOURCE_VBLANK1..6. It signals >>> start of vblank, but the underlying hw interrupts are actually a >>> properly programmed VLINE0 irq on DCE and a VSTARTUP irq on DCN. >> >> >> Ah, I see what you mean. Maybe this is for the better to share the same >> names then. I'll defer this to Harry. >> I'd tend to agree with Mario. I think it's best to keep the same semantic for VUPDATE. The regular VUPDATE has some interaction with the master lock. I imagine we want something that fires independently of it, which looks to be the _NO_LOCK version. That said, both VSTARTUP and VUPDATE can occur before VSYNC on DCN. With most timings this probably won't occur but if our back porch is really small we'd see that happening. If we need to guarantee that this interrupt occurs no sooner than vline 0 we will need to register a vline IRQ. As for VSTARTUP and VUPDATE, VSTARTUP is the IRQ that has an impact on the behavior of render clients as it's the deadline for frame submissions. After VSTARTUP any new framebuffer address update is postponed to the next frame (unless we do immediate flip). So for now VUPDATE_NO_LOCK is probably fine and will improve our situation except for VRR displays with a really short back porch. Not sure those even exist. >>> >>> Of course this all assumes we need to use the NO_LOCK variant on DCN? >>> We haven't tested what the regular VUPDATE_IRQ does, because i don't >>> have a suitable test machine, and my use of the NO_LOCK variant was >>> just based on my interpretation of this little comment in the DCN >>> header file: >>> >>> #define DCN_1_0__SRCID__OTG0_IHC_V_UPDATE_NO_LOCK_INTERRUPT 0x57 // >>> "OTG0 VUPDATE event without lock interrupt, VUPDATE is update event >>> for double buffered registers" >>> >>> and the absence of any explanatory comment in the define of regular >>> V_UPDATE: >>> >>> #define DCN_1_0__SRCID__DC_D1_OTG_V_UPDATE 0x18 // D1 : OTG V_update >>> OTG1_IHC_V_UPDATE_INTERRUPT >>> >>> I assumed the NO_LOCK means not affected by the state of any of the hw >>> locks, so regular V_UPDATE might be affected by them. You agreed with >>> that, but we never tested what regular V_UPDATE would do on DCN. Do we >>> actually know for sure from hw specs that it would not work, ie. not >>> unconditionally fire the IRQ at every end of VBLANK, as we need? >> >>
Re: randr: Virtual monitor not present with MST display
On 2019-03-18 5:58 p.m., Paul Menzel wrote: > > Dear Harry, > ... snip ... >> >> Michel, do you know if this is supposed to work with >> xf86-video-amdgpu? When I've tried it before I didn't have any luck but >> didn't have time to look into it. > > Sorry, what is your question. With the commit from the merge request applied > it works here. Also, the commit was added to the master branch in the mean > time. > Ah, of course. Somehow I thought this was still targetting the modesetting driver and didn't notice it's on video-amdgpu. Apologies for the confusion. Harry > > Kind regards, > > Paul ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: randr: Virtual monitor not present with MST display
On 2019-03-08 4:11 a.m., Michel Dänzer wrote: > On 2019-03-06 5:35 p.m., Paul Menzel wrote: >> On 03/06/19 15:55, Michel Dänzer wrote: >>> On 2019-03-06 1:41 p.m., Paul Menzel wrote: On 03/05/19 20:07, Alex Deucher wrote: > On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote: >> Using the MST display Dell UP3214Q (two panels) with an AMD system, >> the virtual monitor object is not created. GDM and Xfce consider both >> panels as separate screens (`xrandr --listmonitors`). >> >> [...] I didn’t provide the output of xrandr in my previous message. $ xrandr --listmonitors Monitors: 2 0: +DisplayPort-9 1920/698x2160/392+0+0 DisplayPort-9 1: +DisplayPort-10 1920/698x2160/392+1920+0 DisplayPort-10 Please find the X.Org X Server log attached. >> With an Intel system, the monitor object is shown. To clarify, the modesetting driver is used with the Intel hardware. >>> >>> Does this work better with the modesetting driver on the AMD system? >> >> With Linux 4.19.19, there was the same problem with the modesetting driver >> during my limited testing. >> >> Updating to Linux 4.20.13, it worked with the modesetting driver, but the >> AMDGPU driver still failed to properly utilize the MST monitor. > > Does > https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/32 > help? > Michel, do you know if this is supposed to work with xf86-video-amdgpu? When I've tried it before I didn't have any luck but didn't have time to look into it. Harry > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Only put primary planes into the mode_info->planes list
On 2019-03-14 12:53 p.m., Nicholas Kazlauskas wrote:
> We want DRM planes to be initialized in the following order:
>
> - primary planes
> - overlay planes
> - cursor planes
>
> to support existing userspace expectations for plane z-ordering. This
> means that we also need to register CRTCs after all planes have been
> initialized since overlay planes can be placed on any CRTC.
>
> So the only reason why we have the mode_info->planes list is to
> remember the primary planes for use later when we need to register
> the CRTC.
>
> Overlay planes have no purpose being in this list. DRM will cleanup
> any planes that we've registered for us, so the only planes that need to
> be explicitly cleaned up are the ones that have failed to register.
>
> By dropping the explicit free on every plane in the mode_info->planes
> list this patch also fixes a double-free in the case where we fail to
> initialize only some of the planes.
>
> Cc: Leo Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index cde0da3ae964..f770de36121f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1818,8 +1818,6 @@ static int initialize_plane(struct
> amdgpu_display_manager *dm,
> int ret = 0;
>
> plane = kzalloc(sizeof(struct drm_plane), GFP_KERNEL);
> - mode_info->planes[plane_id] = plane;
> -
> if (!plane) {
> DRM_ERROR("KMS: Failed to allocate plane\n");
> return -ENOMEM;
> @@ -1836,13 +1834,17 @@ static int initialize_plane(struct
> amdgpu_display_manager *dm,
> if (plane_id >= dm->dc->caps.max_streams)
> possible_crtcs = 0xff;
>
> - ret = amdgpu_dm_plane_init(dm, mode_info->planes[plane_id],
> possible_crtcs);
> + ret = amdgpu_dm_plane_init(dm, plane, possible_crtcs);
>
> if (ret) {
> DRM_ERROR("KMS: Failed to initialize plane\n");
> + kfree(plane);
> return ret;
> }
>
> + if (mode_info)
> + mode_info->planes[plane_id] = plane;
> +
> return ret;
> }
>
> @@ -1885,7 +1887,7 @@ static int amdgpu_dm_initialize_drm_device(struct
> amdgpu_device *adev)
> struct amdgpu_encoder *aencoder = NULL;
> struct amdgpu_mode_info *mode_info = >mode_info;
> uint32_t link_cnt;
> - int32_t overlay_planes, primary_planes, total_planes;
> + int32_t overlay_planes, primary_planes;
> enum dc_connection_type new_connection_type = dc_connection_none;
>
> link_cnt = dm->dc->caps.max_links;
> @@ -1914,9 +1916,7 @@ static int amdgpu_dm_initialize_drm_device(struct
> amdgpu_device *adev)
>
> /* There is one primary plane per CRTC */
> primary_planes = dm->dc->caps.max_streams;
> -
> - total_planes = primary_planes + overlay_planes;
> - ASSERT(total_planes <= AMDGPU_MAX_PLANES);
> + ASSERT(primary_planes <= AMDGPU_MAX_PLANES);
>
> /*
>* Initialize primary planes, implicit planes for legacy IOCTLS.
> @@ -1937,7 +1937,7 @@ static int amdgpu_dm_initialize_drm_device(struct
> amdgpu_device *adev)
>* Order is reversed to match iteration order in atomic check.
>*/
> for (i = (overlay_planes - 1); i >= 0; i--) {
> - if (initialize_plane(dm, mode_info, primary_planes + i,
> + if (initialize_plane(dm, NULL, primary_planes + i,
>DRM_PLANE_TYPE_OVERLAY)) {
> DRM_ERROR("KMS: Failed to initialize overlay plane\n");
> goto fail;
> @@ -2041,8 +2041,7 @@ static int amdgpu_dm_initialize_drm_device(struct
> amdgpu_device *adev)
> fail:
> kfree(aencoder);
> kfree(aconnector);
> - for (i = 0; i < primary_planes; i++)
> - kfree(mode_info->planes[i]);
> +
> return -EINVAL;
> }
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Respect DRM framebuffer info for video surfaces
On 2019-03-13 12:35 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Incorrect hardcoded assumptions are made regarding luma and chroma
> alignment. The actual values set for the DRM framebuffer should be used
> when programming the address.
>
> [How]
> Respect the given pitch for both luma and chroma planes - it's not like
> we can force the alignment to anything else at this point anyway.
>
> Use the FB offset for the chroma planes directly. DRM already
> provides this to us so there's no need to calculate it manually.
>
> While we don't actually use the chroma surface size parameters on Raven,
> these should have technically been fb->width / 2 and fb->height / 2
> since the chroma plane is half size of the luma plane for NV12.
>
> Leave a TODO indicating that those should be set based on the actual
> surface format instead since this is only correct for YUV420 formats.
>
> Cc: Leo Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 +--
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index cde0da3ae964..5f1e23ba75e1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2465,8 +2465,7 @@ fill_plane_tiling_attributes(struct amdgpu_device *adev,
> address->grph.addr.high_part = upper_32_bits(afb->address);
> } else {
> const struct drm_framebuffer *fb = >base;
> - uint64_t awidth = ALIGN(fb->width, 64);
> - uint64_t chroma_addr = afb->address + awidth * fb->height;
> + uint64_t chroma_addr = afb->address + fb->offsets[1];
>
> address->type = PLN_ADDR_TYPE_VIDEO_PROGRESSIVE;
> address->video_progressive.luma_addr.low_part =
> @@ -2542,7 +2541,6 @@ static int fill_plane_attributes_from_fb(struct
> amdgpu_device *adev,
>const struct amdgpu_framebuffer
> *amdgpu_fb)
> {
> uint64_t tiling_flags;
> - unsigned int awidth;
> const struct drm_framebuffer *fb = _fb->base;
> int ret = 0;
> struct drm_format_name_buf format_name;
> @@ -2602,20 +2600,21 @@ static int fill_plane_attributes_from_fb(struct
> amdgpu_device *adev,
> plane_state->color_space = COLOR_SPACE_SRGB;
>
> } else {
> - awidth = ALIGN(fb->width, 64);
> -
> plane_state->plane_size.video.luma_size.x = 0;
> plane_state->plane_size.video.luma_size.y = 0;
> - plane_state->plane_size.video.luma_size.width = awidth;
> + plane_state->plane_size.video.luma_size.width = fb->width;
> plane_state->plane_size.video.luma_size.height = fb->height;
> - /* TODO: unhardcode */
> - plane_state->plane_size.video.luma_pitch = awidth;
> + plane_state->plane_size.video.luma_pitch =
> + fb->pitches[0] / fb->format->cpp[0];
>
> plane_state->plane_size.video.chroma_size.x = 0;
> plane_state->plane_size.video.chroma_size.y = 0;
> - plane_state->plane_size.video.chroma_size.width = awidth;
> - plane_state->plane_size.video.chroma_size.height = fb->height;
> - plane_state->plane_size.video.chroma_pitch = awidth / 2;
> + /* TODO: set these based on surface format */
> + plane_state->plane_size.video.chroma_size.width = fb->width / 2;
> + plane_state->plane_size.video.chroma_size.height = fb->height /
> 2;
> +
> + plane_state->plane_size.video.chroma_pitch =
> + fb->pitches[1] / fb->format->cpp[1];
>
> /* TODO: unhardcode */
> plane_state->color_space = COLOR_SPACE_YCBCR709;
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: don't call dm_pp_ function from an fpu block
On 2019-02-26 4:24 p.m., Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.12, v4.19.25, v4.14.103,
> v4.9.160, v4.4.176, v3.18.136.
>
> v4.20.12: Build OK!
> v4.19.25: Build OK!
> v4.14.103: Failed to apply! Possible dependencies:
> 00893681a0ff ("drm/amd/display: Reject PPLib clock values if they are
> invalid")
> 1b0c0f9dc5ca ("drm/amdgpu: move userptr BOs to CPU domain during CS v2")
> 1ed3d2567c80 ("drm/amdgpu: keep the MMU lock until the update ends v4")
> 3fe89771cb0a ("drm/amdgpu: stop reserving the BO in the MMU callback v3")
> 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
> 60de1c1740f3 ("drm/amdgpu: use a rw_semaphore for MMU notifiers")
> 64b44524d4b2 ("drm/amd/display: bw debug options now apply to dml as
> well")
> 65111f25f1fe ("drm/amd/display: change dcn_ip and dcn_soc into pointers")
> 74c49c7ac14f ("drm/amdgpu/display: Add calcs code for DCN")
> 9037d802a978 ("drm/amd/display: refactor bw related variable structure in
> val_ctx")
> 9a18999640fa ("drm/amdgpu: move MMU notifier related defines to
> amdgpu_mn.h")
> 9cca0b8e5df0 ("drm/amdgpu: move amdgpu_cs_sysvm_access_required into
> find_mapping")
> a216ab09955d ("drm/amdgpu: fix userptr put_page handling")
> b72cf4fca2bb ("drm/amdgpu: move taking mmap_sem into get_user_pages v2")
> b884a2ec5863 ("drm/amd/display: call pplib to update clocks")
> ca666a3c298f ("drm/amdgpu: stop using BO status for user pages")
> fb3466a450cc ("drm/amd/display: Flattening core_dc to dc")
>
> v4.9.160: Failed to apply! Possible dependencies:
> 00893681a0ff ("drm/amd/display: Reject PPLib clock values if they are
> invalid")
> 1cec20f0ea0e ("dma-buf: Restart reservation_object_wait_timeout_rcu()
> after writes")
> 3fe89771cb0a ("drm/amdgpu: stop reserving the BO in the MMU callback v3")
> 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
> 4df654d293c6 ("drm/amdgpu: move amdgpu_uvd structure to uvd header")
> 5e5681788bef ("drm/amdgpu: move amdgpu_vce structure to vce header")
> 64b44524d4b2 ("drm/amd/display: bw debug options now apply to dml as
> well")
> 65111f25f1fe ("drm/amd/display: change dcn_ip and dcn_soc into pointers")
> 660e855813f7 ("amdgpu: use drm sync objects for shared semaphores (v6)")
> 74c49c7ac14f ("drm/amdgpu/display: Add calcs code for DCN")
> 78010cd9736e ("dma-buf/fence: add an lockdep_assert_held()")
> 9037d802a978 ("drm/amd/display: refactor bw related variable structure in
> val_ctx")
> 95aa13f6b196 ("drm/amdgpu: move amdgpu_vcn structure to vcn header")
> 95d0906f8506 ("drm/amdgpu: add initial vcn support and decode tests")
> 9a18999640fa ("drm/amdgpu: move MMU notifier related defines to
> amdgpu_mn.h")
> b636922553ee ("drm/amdgpu: only move VM BOs in the LRU during validation
> v2")
> b72cf4fca2bb ("drm/amdgpu: move taking mmap_sem into get_user_pages v2")
> b884a2ec5863 ("drm/amd/display: call pplib to update clocks")
> f54d1867005c ("dma-buf: Rename struct fence to dma_fence")
> fb3466a450cc ("drm/amd/display: Flattening core_dc to dc")
> fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu() after
> writes")
>
> v4.4.176: Failed to apply! Possible dependencies:
> 00893681a0ff ("drm/amd/display: Reject PPLib clock values if they are
> invalid")
> 1f7371b2a5fa ("drm/amd/powerplay: add basic powerplay framework")
> 288912cb95d1 ("drm/amdgpu: use $(src) in Makefile (v2)")
> 3c0eea6c35d9 ("drm/amdgpu: put VM page tables directly into duplicates
> list")
> 3f99dd814a6f ("drm/amdgpu: save and restore UVD context with suspend and
> resume")
> 4325198180e5 ("drm/amdgpu: remove GART page addr array")
> 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
> 4acabfe3793e ("drm/amdgpu: fix num_ibs check")
> 4df654d293c6 ("drm/amdgpu: move amdgpu_uvd structure to uvd header")
> 50838c8cc413 ("drm/amdgpu: add proper job alloc/free functions")
> 56467ebfb254 ("drm/amdgpu: split VM PD and PT handling during CS")
> 5e5681788bef ("drm/amdgpu: move amdgpu_vce structure to vce header")
> 64b44524d4b2 ("drm/amd/display: bw debug options now apply to dml as
> well")
> 65111f25f1fe ("drm/amd/display: change dcn_ip and dcn_soc into pointers")
> 7270f8391df1 ("drm/amdgpu: add amdgpu_set_ib_value helper (v2)")
> 74c49c7ac14f ("drm/amdgpu/display: Add calcs code for DCN")
> 9037d802a978 ("drm/amd/display: refactor bw related variable structure in
> val_ctx")
> 95aa13f6b196 ("drm/amdgpu: move amdgpu_vcn structure to vcn header")
> 9a18999640fa ("drm/amdgpu: move MMU notifier related defines to
> amdgpu_mn.h")
> a1d29476d666 ("drm/amdgpu: optionally enable GART debugfs
Re: [PATCH] drm/amdgpu: fix compile warnings
On 2019-03-01 11:46 a.m., Wentland, Harry wrote:
> On 2019-03-01 11:43 a.m., Bhawanpreet Lakha wrote:
>> Fixes the warnings below
>>
>> warning: ‘ta_hdr’ may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>> warning: ISO C90 forbids mixed declarations and code
>> [-Wdeclaration-after-statement]
>> warning: unused variable ‘ras_cmd’ [-Wunused-variable]
>> warning: comparison of distinct pointer types lacks a cast
>> Signed-off-by: Bhawanpreet Lakha
>
> If these are all based on the one RAS patch please leave a Fixes: tag with
> that patch.
>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 1 -
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
>> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
>> 5 files changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> index 933822eb1227..0bbbc7cd2bea 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> @@ -927,7 +927,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev,
>> void *data, struct drm_file
>> if (!ras)
>> return -EINVAL;
>> return copy_to_user(out, >features,
>> -min(size, sizeof(ras->features))) ? -EFAULT : 0;
>> +min((size_t)size, sizeof(ras->features))) ?
>> -EFAULT : 0;
>
> shouldn't need the 2nd size_t case (on sizeof)
whoops, copy-pasted the comment from an earlier iteration. just ignore.
Harry
>
>> }
>> default:
>> DRM_DEBUG_KMS("Invalid request %d\n", info->query);
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
>> index 607c696db56b..7e3e1d588d74 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
>> @@ -654,7 +654,6 @@ static int psp_ras_terminate(struct psp_context *psp)
>>
>> static int psp_ras_initialize(struct psp_context *psp)
>> {
>> -struct ta_ras_shared_memory *ras_cmd;
>> int ret;
>>
>> if (!psp->ras.ras_initialized) {
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> index 604762263221..29552e39816c 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> @@ -142,7 +142,7 @@ static ssize_t amdgpu_ras_debugfs_read(struct file *f,
>> char __user *buf,
>> return 0;
>>
>> s -= *pos;
>> -s = min(s, size);
>> +s = min((size_t)s, size);
>
> size is already size_t, no need to cast that again
>
> With those fixed this patch is
> Reviewed-by: Harry Wentland
>
> Harry
>
>>
>> if (copy_to_user(buf, [*pos], s))
>> return -EINVAL;
>> @@ -159,7 +159,7 @@ static ssize_t amdgpu_ras_debugfs_write(struct file *f,
>> const char __user *buf,
>> struct ras_inject_if info = {
>> .head = obj->head,
>> };
>> -ssize_t s = min(64ULL, size);
>> +ssize_t s = min((size_t)64ULL, size);
>> char val[64];
>> char *str = val;
>> memset(val, 0, sizeof(val));
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> index e1d3bef5a60c..88c45f990f05 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> @@ -4813,11 +4813,11 @@ static int gfx_v9_0_cp_ecc_error_irq(struct
>> amdgpu_device *adev,
>>struct amdgpu_irq_src *source,
>>struct amdgpu_iv_entry *entry)
>> {
>> -DRM_ERROR("CP ECC ERROR IRQ\n");
>> struct ras_dispatch_if ih_data = {
>> .head = *adev->gfx.ras_if,
>> .entry = entry,
>> };
>> +DRM_ERROR("CP ECC ERROR IRQ\n");
>> amdgpu_ras_interrupt_dispatch(adev, _data);
>> return 0;
>> }
>> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
>> b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
>> index 8f694968c0ad..2f6f82d13cc8 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
>> @@ -48,7 +48,7 @@ static int psp_v11_0_init_microcode(struct psp_context
>> *psp)
>> int err = 0;
>> const struct psp_firmware_header_v1_0 *sos_hdr;
>> const struct psp_firmware_header_v1_0 *asd_hdr;
>> -const struct ta_firmware_header_v1_0 *ta_hdr;
>> +const struct ta_firmware_header_v1_0 *ta_hdr = NULL;
>>
>> DRM_DEBUG("\n");
>>
>>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: fix compile warnings
On 2019-03-01 11:43 a.m., Bhawanpreet Lakha wrote:
> Fixes the warnings below
>
> warning: ‘ta_hdr’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> warning: ISO C90 forbids mixed declarations and code
> [-Wdeclaration-after-statement]
> warning: unused variable ‘ras_cmd’ [-Wunused-variable]
> warning: comparison of distinct pointer types lacks a cast
> Signed-off-by: Bhawanpreet Lakha
If these are all based on the one RAS patch please leave a Fixes: tag with that
patch.
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> 5 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 933822eb1227..0bbbc7cd2bea 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -927,7 +927,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file
> if (!ras)
> return -EINVAL;
> return copy_to_user(out, >features,
> - min(size, sizeof(ras->features))) ? -EFAULT : 0;
> + min((size_t)size, sizeof(ras->features))) ?
> -EFAULT : 0;
shouldn't need the 2nd size_t case (on sizeof)
> }
> default:
> DRM_DEBUG_KMS("Invalid request %d\n", info->query);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index 607c696db56b..7e3e1d588d74 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -654,7 +654,6 @@ static int psp_ras_terminate(struct psp_context *psp)
>
> static int psp_ras_initialize(struct psp_context *psp)
> {
> - struct ta_ras_shared_memory *ras_cmd;
> int ret;
>
> if (!psp->ras.ras_initialized) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 604762263221..29552e39816c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -142,7 +142,7 @@ static ssize_t amdgpu_ras_debugfs_read(struct file *f,
> char __user *buf,
> return 0;
>
> s -= *pos;
> - s = min(s, size);
> + s = min((size_t)s, size);
size is already size_t, no need to cast that again
With those fixed this patch is
Reviewed-by: Harry Wentland
Harry
>
> if (copy_to_user(buf, [*pos], s))
> return -EINVAL;
> @@ -159,7 +159,7 @@ static ssize_t amdgpu_ras_debugfs_write(struct file *f,
> const char __user *buf,
> struct ras_inject_if info = {
> .head = obj->head,
> };
> - ssize_t s = min(64ULL, size);
> + ssize_t s = min((size_t)64ULL, size);
> char val[64];
> char *str = val;
> memset(val, 0, sizeof(val));
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index e1d3bef5a60c..88c45f990f05 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -4813,11 +4813,11 @@ static int gfx_v9_0_cp_ecc_error_irq(struct
> amdgpu_device *adev,
> struct amdgpu_irq_src *source,
> struct amdgpu_iv_entry *entry)
> {
> - DRM_ERROR("CP ECC ERROR IRQ\n");
> struct ras_dispatch_if ih_data = {
> .head = *adev->gfx.ras_if,
> .entry = entry,
> };
> + DRM_ERROR("CP ECC ERROR IRQ\n");
> amdgpu_ras_interrupt_dispatch(adev, _data);
> return 0;
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> index 8f694968c0ad..2f6f82d13cc8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> @@ -48,7 +48,7 @@ static int psp_v11_0_init_microcode(struct psp_context *psp)
> int err = 0;
> const struct psp_firmware_header_v1_0 *sos_hdr;
> const struct psp_firmware_header_v1_0 *asd_hdr;
> - const struct ta_firmware_header_v1_0 *ta_hdr;
> + const struct ta_firmware_header_v1_0 *ta_hdr = NULL;
>
> DRM_DEBUG("\n");
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 3/3] drm/dsc: Change infoframe_pack to payload_pack
On 2019-02-13 9:45 a.m., David Francis wrote:
> The function drm_dsc_pps_infoframe_pack only
> packed the payload portion of the infoframe.
> Change the input struct to the PPS payload
> to clarify the function's purpose and allow
> for drivers with their own handling of sdp.
> (e.g. drivers with their own struct for
> all SDP transactions)
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Again, ideally we'd want an AB from i915 guys as well.
Harry
> ---
> drivers/gpu/drm/drm_dsc.c | 86 +++
> drivers/gpu/drm/i915/intel_vdsc.c | 2 +-
> include/drm/drm_dsc.h | 2 +-
> 3 files changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 9e675dd39a44..4ada4d4f59ac 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -38,42 +38,42 @@ void drm_dsc_dp_pps_header_init(struct
> drm_dsc_pps_infoframe *pps_sdp)
> EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
>
> /**
> - * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
> + * drm_dsc_pps_payload_pack() - Populates the DSC PPS payload
> * using the DSC configuration parameters in the order expected
> * by the DSC Display Sink device. For the DSC, the sink device
> * expects the PPS payload in the big endian format for the fields
> * that span more than 1 byte.
> *
> - * @pps_sdp:
> - * Secondary data packet for DSC Picture Parameter Set
> + * @pps_payload:
> + * DSC Picture Parameter Set
> * @dsc_cfg:
> * DSC Configuration data filled by driver
> */
> -void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
> +void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set
> *pps_payload,
> const struct drm_dsc_config *dsc_cfg)
> {
> int i;
>
> /* Protect against someone accidently changing struct size */
> - BUILD_BUG_ON(sizeof(pps_sdp->pps_payload) !=
> + BUILD_BUG_ON(sizeof(*pps_payload) !=
>DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
>
> - memset(_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
> + memset(pps_payload, 0, sizeof(*pps_payload));
>
> /* PPS 0 */
> - pps_sdp->pps_payload.dsc_version =
> + pps_payload->dsc_version =
> dsc_cfg->dsc_version_minor |
> dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
>
> /* PPS 1, 2 is 0 */
>
> /* PPS 3 */
> - pps_sdp->pps_payload.pps_3 =
> + pps_payload->pps_3 =
> dsc_cfg->line_buf_depth |
> dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
>
> /* PPS 4 */
> - pps_sdp->pps_payload.pps_4 =
> + pps_payload->pps_4 =
> ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT) |
> dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> @@ -82,7 +82,7 @@ void drm_dsc_pps_infoframe_pack(struct
> drm_dsc_pps_infoframe *pps_sdp,
> dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
>
> /* PPS 5 */
> - pps_sdp->pps_payload.bits_per_pixel_low =
> + pps_payload->bits_per_pixel_low =
> (dsc_cfg->bits_per_pixel & DSC_PPS_LSB_MASK);
>
> /*
> @@ -93,103 +93,103 @@ void drm_dsc_pps_infoframe_pack(struct
> drm_dsc_pps_infoframe *pps_sdp,
>*/
>
> /* PPS 6, 7 */
> - pps_sdp->pps_payload.pic_height = cpu_to_be16(dsc_cfg->pic_height);
> + pps_payload->pic_height = cpu_to_be16(dsc_cfg->pic_height);
>
> /* PPS 8, 9 */
> - pps_sdp->pps_payload.pic_width = cpu_to_be16(dsc_cfg->pic_width);
> + pps_payload->pic_width = cpu_to_be16(dsc_cfg->pic_width);
>
> /* PPS 10, 11 */
> - pps_sdp->pps_payload.slice_height = cpu_to_be16(dsc_cfg->slice_height);
> + pps_payload->slice_height = cpu_to_be16(dsc_cfg->slice_height);
>
> /* PPS 12, 13 */
> - pps_sdp->pps_payload.slice_width = cpu_to_be16(dsc_cfg->slice_width);
> + pps_payload->slice_width = cpu_to_be16(dsc_cfg->slice_width);
>
> /* PPS 14, 15 */
> - pps_sdp->pps_payload.chunk_size =
> cpu_to_be16(dsc_cfg->slice_chunk_size);
> + pps_payload->chunk_size = cpu_to_be16(dsc_cfg->slice_chunk_size);
>
> /* PPS 16 */
> - pps_sdp->pps_payload.initial_xmit_delay_high =
> + pps_payload->initial_xmit_delay_high =
> ((dsc_cfg->initial_xmit_delay &
> DSC_PPS_INIT_XMIT_DELAY_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT);
>
> /* PPS 17 */
> - pps_sdp->pps_payload.initial_xmit_delay_low =
> + pps_payload->initial_xmit_delay_low =
> (dsc_cfg->initial_xmit_delay & DSC_PPS_LSB_MASK);
>
> /* PPS 18, 19 */
> - pps_sdp->pps_payload.initial_dec_delay =
> + pps_payload->initial_dec_delay =
> cpu_to_be16(dsc_cfg->initial_dec_delay);
>
> /* PPS 20 is 0 */
>
> /* PPS 21 */
> -
Re: [PATCH 2/3] drm/dsc: Add native 420 and 422 support to compute_rc_params
On 2019-02-13 9:45 a.m., David Francis wrote:
> Native 420 and 422 transfer modes are new in DSC1.2
>
> In these modes, each two pixels of a slice are treated as one
> pixel, so the slice width is half as large (round down) for
> the purposes of calucating the groups per line and chunk size
> in bytes
>
> In native 422 mode, each pixel has four components, so the
> mux component of a group is larger by one additional mux word
> and one additional component
>
> Now that there is native 422 support, the configuration option
> previously called enable422 is renamed to simple_422 to avoid
> confusion
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_dsc.c | 31 +++
> drivers/gpu/drm/i915/intel_vdsc.c | 4 ++--
> include/drm/drm_dsc.h | 4 ++--
> 3 files changed, 27 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 4b0e3c9c3ff8..9e675dd39a44 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -77,7 +77,7 @@ void drm_dsc_pps_infoframe_pack(struct
> drm_dsc_pps_infoframe *pps_sdp,
> ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT) |
> dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> - dsc_cfg->enable422 << DSC_PPS_SIMPLE422_SHIFT |
> + dsc_cfg->simple_422 << DSC_PPS_SIMPLE422_SHIFT |
> dsc_cfg->convert_rgb << DSC_PPS_CONVERT_RGB_SHIFT |
> dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
>
> @@ -246,19 +246,34 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config
> *vdsc_cfg)
> unsigned long final_scale = 0;
> unsigned long rbs_min = 0;
>
> - /* Number of groups used to code each line of a slice */
> - groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> -DSC_RC_PIXELS_PER_GROUP);
> + if (vdsc_cfg->native_420 || vdsc_cfg->native_422) {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width / 2,
> +DSC_RC_PIXELS_PER_GROUP);
>
> - /* chunksize in Bytes */
> - vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> - vdsc_cfg->bits_per_pixel,
> - (8 * 16));
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width
> / 2 *
> +
> vdsc_cfg->bits_per_pixel,
> + (8 * 16));
> + } else {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width
> *
> +
> vdsc_cfg->bits_per_pixel,
> + (8 * 16));
> + }
>
> if (vdsc_cfg->convert_rgb)
> num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> (4 * vdsc_cfg->bits_per_component + 4)
> - 2);
> + else if (vdsc_cfg->native_422)
> + num_extra_mux_bits = 4 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 3 * (4 * vdsc_cfg->bits_per_component) - 2;
> else
> num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> (4 * vdsc_cfg->bits_per_component + 4) +
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index c76cec8bfb74..7702c5c8b3f2 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -369,7 +369,7 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
> DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
>
> /* Gen 11 does not support YCbCr */
> - vdsc_cfg->enable422 = false;
> + vdsc_cfg->simple_422 = false;
> /* Gen 11 does not support VBR */
> vdsc_cfg->vbr_enable = false;
> vdsc_cfg->block_pred_enable
Re: [PATCH 1/3] drm/i915: Move dsc rate params compute into drm
On 2019-02-13 9:45 a.m., David Francis wrote:
> The function intel_compute_rc_parameters is part of the dsc spec
> and is not driver-specific. Other drm drivers might like to use
> it. The function is not changed; just moved and renamed.
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
This one also needs an RB or AB from i915 guys.
Harry
> ---
> drivers/gpu/drm/drm_dsc.c | 133 ++
> drivers/gpu/drm/i915/intel_vdsc.c | 125 +---
> include/drm/drm_dsc.h | 1 +
> 3 files changed, 135 insertions(+), 124 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index bc2b23adb072..4b0e3c9c3ff8 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -226,3 +227,135 @@ void drm_dsc_pps_infoframe_pack(struct
> drm_dsc_pps_infoframe *pps_sdp,
> /* PPS 94 - 127 are O */
> }
> EXPORT_SYMBOL(drm_dsc_pps_infoframe_pack);
> +
> +/**
> + * drm_dsc_compute_rc_parameters() - Write rate control
> + * parameters to the dsc configuration. Some configuration
> + * fields must be present beforehand.
> + *
> + * @dsc_cfg:
> + * DSC Configuration data partially filled by driver
> + */
> +int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
> +{
> + unsigned long groups_per_line = 0;
> + unsigned long groups_total = 0;
> + unsigned long num_extra_mux_bits = 0;
> + unsigned long slice_bits = 0;
> + unsigned long hrd_delay = 0;
> + unsigned long final_scale = 0;
> + unsigned long rbs_min = 0;
> +
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> + vdsc_cfg->bits_per_pixel,
> + (8 * 16));
> +
> + if (vdsc_cfg->convert_rgb)
> + num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4)
> + - 2);
> + else
> + num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 2 * (4 * vdsc_cfg->bits_per_component) - 2;
> + /* Number of bits in one Slice */
> + slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
> +
> + while ((num_extra_mux_bits > 0) &&
> +((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
> + num_extra_mux_bits--;
> +
> + if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
> + vdsc_cfg->initial_scale_value = groups_per_line + 8;
> +
> + /* scale_decrement_interval calculation according to DSC spec 1.11 */
> + if (vdsc_cfg->initial_scale_value > 8)
> + vdsc_cfg->scale_decrement_interval = groups_per_line /
> + (vdsc_cfg->initial_scale_value - 8);
> + else
> + vdsc_cfg->scale_decrement_interval =
> DSC_SCALE_DECREMENT_INTERVAL_MAX;
> +
> + vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
> + (vdsc_cfg->initial_xmit_delay *
> + vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
> +
> + if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
> + DRM_DEBUG_KMS("FinalOfs < RcModelSze for this
> InitialXmitDelay\n");
> + return -ERANGE;
> + }
> +
> + final_scale = (vdsc_cfg->rc_model_size * 8) /
> + (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
> + if (vdsc_cfg->slice_height > 1)
> + /*
> + * NflBpgOffset is 16 bit value with 11 fractional bits
> + * hence we multiply by 2^11 for preserving the
> + * fractional part
> + */
> + vdsc_cfg->nfl_bpg_offset =
> DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
> + (vdsc_cfg->slice_height
> - 1));
> + else
> + vdsc_cfg->nfl_bpg_offset = 0;
> +
> + /* 2^16 - 1 */
> + if (vdsc_cfg->nfl_bpg_offset > 65535) {
> + DRM_DEBUG_KMS("NflBpgOffset is too large for this slice
> height\n");
> + return -ERANGE;
> + }
> +
> + /* Number of groups used to code the entire slice */
> + groups_total = groups_per_line * vdsc_cfg->slice_height;
> +
> + /* slice_bpg_offset is 16 bit value with 11 fractional bits */
> + vdsc_cfg->slice_bpg_offset = DIV_ROUND_UP(((vdsc_cfg->rc_model_size -
> + vdsc_cfg->initial_offset +
> +
Re: BUG - unable to handle null pointer, bisected - drm/amd/display: add gpio lock/unlock
On 2019-02-07 2:21 p.m., Wentland, Harry wrote: > On 2019-02-06 4:48 a.m., Przemek Socha wrote: >> Good morning, >> >> on my Lenovo G50-45 a6310 APU with R4 Mullins commit >> e261568f94d6c37ebb94d3c4b3f8a3085375dd9d is causing kernel Oops (unable to >> handle NULL pointer). > > Thanks. Obviously this change leads to a NULL pointer dereference as > dal_gpio_open derefs it. > >> - hpd_gpio = get_hpd_gpio(link->ctx->dc_bios, link->link_id, >> link->ctx->gpio_service); >> - >> - if (hpd_gpio != NULL) >> - link->irq_source_hpd = dal_irq_get_source(hpd_gpio); >> + link->hpd_gpio = get_hpd_gpio(link->ctx->dc_bios, link->link_id, >> link->ctx->gpio_service); >> + dal_gpio_open(link->hpd_gpio, GPIO_MODE_INTERRUPT); >> + dal_gpio_unlock_pin(link->hpd_gpio); >> + if (link->hpd_gpio != NULL) >> + link->irq_source_hpd = dal_irq_get_source(link->hpd_gpio); > > I'll post a fix shortly. > Fix merged to amd-staging-drm-next. Harry > Harry > >> Cross-checked by reverting troublesome commit and machine without it is >> working fine. >> >> Here is a part of the Oops message from pstore: >> >> >> <1>[ 13.200310] BUG: unable to handle kernel NULL pointer dereference at >> 0008 >> <1>[ 13.200323] #PF error: [normal kernel read fault] >> <6>[ 13.200328] PGD 0 P4D 0 >> <4>[ 13.200335] Oops: [#1] PREEMPT SMP >> <4>[ 13.200342] CPU: 2 PID: 2961 Comm: udevd Not tainted 5.0.0-rc1+ #47 >> <4>[ 13.200347] Hardware name: LENOVO 80E3/Lancer 5B2, BIOS >> A2CN45WW(V2.13) >> 08/04/2016 >> <4>[ 13.200450] RIP: 0010:dal_gpio_open_ex+0x0/0x30 [amdgpu] >> <4>[ 13.200456] Code: d6 48 89 de 48 89 ef e8 6e f8 ff ff 84 c0 74 c7 48 >> 89 e8 >> 5b 5d c3 0f 0b 31 ed 5b 48 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 <48> 83 >> 7f 08 00 74 08 0f 0b b8 05 00 00 00 c3 89 77 18 8b 57 14 4c >> <4>[ 13.200466] RSP: 0018:b78e82bb7650 EFLAGS: 00010282 >> <4>[ 13.200471] RAX: RBX: b78e82bb76a4 RCX: >> >> <4>[ 13.200476] RDX: 0006 RSI: 0004 RDI: >> >> <4>[ 13.200480] RBP: a1d695e93300 R08: 0003 R09: >> a1d692456600 >> <4>[ 13.200485] R10: f7dc88574dc0 R11: b78e82bb75b8 R12: >> a1d695c68700 >> <4>[ 13.200490] R13: c07ef5a0 R14: b78e82bb79b8 R15: >> a1d692456600 >> <4>[ 13.200495] FS: 7f9c3fcac300() GS:a1d697b0() >> knlGS: >> >> <4>[ 13.200501] CS: 0010 DS: ES: CR0: 80050033 >> <4>[ 13.200506] CR2: 0008 CR3: 0002124a CR4: >> 000406e0 >> <4>[ 13.200510] Call Trace: >> <4>[ 13.200605] construct+0x15f/0x710 [amdgpu] >> <4>[ 13.200710] link_create+0x2e/0x48 [amdgpu] >> <4>[ 13.200803] dc_create+0x2c0/0x5f0 [amdgpu] >> <4>[ 13.200899] dm_hw_init+0xe0/0x150 [amdgpu] >> <4>[ 13.200990] amdgpu_device_init.cold.38+0xe06/0xf67 [amdgpu] >> <4>[ 13.201002] ? kmalloc_order+0x13/0x38 >> <4>[ 13.201102] amdgpu_driver_load_kms+0x60/0x210 [amdgpu] >> <4>[ 13.201112] drm_dev_register+0x10e/0x150 >> <4>[ 13.201207] amdgpu_pci_probe+0xb8/0x118 [amdgpu] >> <4>[ 13.201217] ? _raw_spin_unlock_irqrestore+0xf/0x28 >> <4>[ 13.201226] pci_device_probe+0xd1/0x158 >> <4>[ 13.201234] really_probe+0xee/0x2a0 >> <4>[ 13.201241] driver_probe_device+0x4a/0xb0 >> <4>[ 13.201247] __driver_attach+0xaf/0xc8 >> <4>[ 13.201253] ? driver_probe_device+0xb0/0xb0 >> <4>[ 13.201258] bus_for_each_dev+0x6f/0xb8 >> <4>[ 13.201265] bus_add_driver+0x197/0x1d8 >> <4>[ 13.201271] ? 0xc0933000 >> <4>[ 13.201276] driver_register+0x66/0xa8 >> <4>[ 13.201281] ? 0xc0933000 >> <4>[ 13.201287] do_one_initcall+0x41/0x1e2 >> <4>[ 13.201294] ? wake_up_page_bit+0x21/0x100 >> <4>[ 13.201301] ? kmem_cache_alloc_trace+0x2e/0x1a0 >> <4>[ 13.201308] ? do_init_module+0x1d/0x1e0 >> <4>[ 13.201315] do_init_module+0x55/0x1e0 >> <4>[ 13.201321] load_module+0x205c/0x2488 >> <4>[ 13.201329] ? vfs_read+0x10e/0x138 >> <4>[ 13.201337] ? __do_sys_fini
Re: BUG - unable to handle null pointer, bisected - drm/amd/display: add gpio lock/unlock
On 2019-02-06 4:48 a.m., Przemek Socha wrote: > Good morning, > > on my Lenovo G50-45 a6310 APU with R4 Mullins commit > e261568f94d6c37ebb94d3c4b3f8a3085375dd9d is causing kernel Oops (unable to > handle NULL pointer). Thanks. Obviously this change leads to a NULL pointer dereference as dal_gpio_open derefs it. > - hpd_gpio = get_hpd_gpio(link->ctx->dc_bios, link->link_id, > link->ctx->gpio_service); > - > - if (hpd_gpio != NULL) > - link->irq_source_hpd = dal_irq_get_source(hpd_gpio); > + link->hpd_gpio = get_hpd_gpio(link->ctx->dc_bios, link->link_id, > link->ctx->gpio_service); > + dal_gpio_open(link->hpd_gpio, GPIO_MODE_INTERRUPT); > + dal_gpio_unlock_pin(link->hpd_gpio); > + if (link->hpd_gpio != NULL) > + link->irq_source_hpd = dal_irq_get_source(link->hpd_gpio); I'll post a fix shortly. Harry > Cross-checked by reverting troublesome commit and machine without it is > working fine. > > Here is a part of the Oops message from pstore: > > > <1>[ 13.200310] BUG: unable to handle kernel NULL pointer dereference at > 0008 > <1>[ 13.200323] #PF error: [normal kernel read fault] > <6>[ 13.200328] PGD 0 P4D 0 > <4>[ 13.200335] Oops: [#1] PREEMPT SMP > <4>[ 13.200342] CPU: 2 PID: 2961 Comm: udevd Not tainted 5.0.0-rc1+ #47 > <4>[ 13.200347] Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13) > 08/04/2016 > <4>[ 13.200450] RIP: 0010:dal_gpio_open_ex+0x0/0x30 [amdgpu] > <4>[ 13.200456] Code: d6 48 89 de 48 89 ef e8 6e f8 ff ff 84 c0 74 c7 48 89 > e8 > 5b 5d c3 0f 0b 31 ed 5b 48 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 <48> 83 > 7f 08 00 74 08 0f 0b b8 05 00 00 00 c3 89 77 18 8b 57 14 4c > <4>[ 13.200466] RSP: 0018:b78e82bb7650 EFLAGS: 00010282 > <4>[ 13.200471] RAX: RBX: b78e82bb76a4 RCX: > > <4>[ 13.200476] RDX: 0006 RSI: 0004 RDI: > > <4>[ 13.200480] RBP: a1d695e93300 R08: 0003 R09: > a1d692456600 > <4>[ 13.200485] R10: f7dc88574dc0 R11: b78e82bb75b8 R12: > a1d695c68700 > <4>[ 13.200490] R13: c07ef5a0 R14: b78e82bb79b8 R15: > a1d692456600 > <4>[ 13.200495] FS: 7f9c3fcac300() GS:a1d697b0() knlGS: > > <4>[ 13.200501] CS: 0010 DS: ES: CR0: 80050033 > <4>[ 13.200506] CR2: 0008 CR3: 0002124a CR4: > 000406e0 > <4>[ 13.200510] Call Trace: > <4>[ 13.200605] construct+0x15f/0x710 [amdgpu] > <4>[ 13.200710] link_create+0x2e/0x48 [amdgpu] > <4>[ 13.200803] dc_create+0x2c0/0x5f0 [amdgpu] > <4>[ 13.200899] dm_hw_init+0xe0/0x150 [amdgpu] > <4>[ 13.200990] amdgpu_device_init.cold.38+0xe06/0xf67 [amdgpu] > <4>[ 13.201002] ? kmalloc_order+0x13/0x38 > <4>[ 13.201102] amdgpu_driver_load_kms+0x60/0x210 [amdgpu] > <4>[ 13.201112] drm_dev_register+0x10e/0x150 > <4>[ 13.201207] amdgpu_pci_probe+0xb8/0x118 [amdgpu] > <4>[ 13.201217] ? _raw_spin_unlock_irqrestore+0xf/0x28 > <4>[ 13.201226] pci_device_probe+0xd1/0x158 > <4>[ 13.201234] really_probe+0xee/0x2a0 > <4>[ 13.201241] driver_probe_device+0x4a/0xb0 > <4>[ 13.201247] __driver_attach+0xaf/0xc8 > <4>[ 13.201253] ? driver_probe_device+0xb0/0xb0 > <4>[ 13.201258] bus_for_each_dev+0x6f/0xb8 > <4>[ 13.201265] bus_add_driver+0x197/0x1d8 > <4>[ 13.201271] ? 0xc0933000 > <4>[ 13.201276] driver_register+0x66/0xa8 > <4>[ 13.201281] ? 0xc0933000 > <4>[ 13.201287] do_one_initcall+0x41/0x1e2 > <4>[ 13.201294] ? wake_up_page_bit+0x21/0x100 > <4>[ 13.201301] ? kmem_cache_alloc_trace+0x2e/0x1a0 > <4>[ 13.201308] ? do_init_module+0x1d/0x1e0 > <4>[ 13.201315] do_init_module+0x55/0x1e0 > <4>[ 13.201321] load_module+0x205c/0x2488 > <4>[ 13.201329] ? vfs_read+0x10e/0x138 > <4>[ 13.201337] ? __do_sys_finit_module+0xba/0xd8 > <4>[ 13.201342] __do_sys_finit_module+0xba/0xd8 > <4>[ 13.201350] do_syscall_64+0x50/0x168 > <4>[ 13.201357] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > <4>[ 13.201364] RIP: 0033:0x7f9c3fdcf409 > <4>[ 13.201371] Code: 18 c3 e8 3a 98 01 00 66 2e 0f 1f 84 00 00 00 00 00 48 > 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> > 3d 01 f0 ff ff 73 01 c3 48 8b 0d 47 6a 0c 00 f7 d8 64 89 01 48 > <4>[ 13.201381] RSP: 002b:7fff9b4824f8 EFLAGS: 0246 ORIG_RAX: > 0139 > <4>[ 13.201389] RAX: ffda RBX: 559d56fe1780 RCX: > 7f9c3fdcf409 > <4>[ 13.201394] RDX: RSI: 559d570385c0 RDI: > 000e > <4>[ 13.201399] RBP: R08: R09: > 7fff9b482610 > <4>[ 13.201404] R10: 000e R11: 0246 R12: > 559d56ff2120 > <4>[ 13.201409] R13: 0002 R14: 559d570385c0 R15: > 559d56fe1780 > <4>[ 13.201416] Modules linked in: kvm_amd kvm ath9k
Re: [PATCH] drm/amdgpu/display: fix compiler errors [-Werror,-Wparentheses-equality]
On 2019-02-04 3:16 a.m., Vishwakarma, Pratik wrote:
> Remove extraneous parentheses around the comparison
> to silence this warning
>
> Signed-off-by: Pratik Vishwakarma
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.c
> b/drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.c
> index 7d102ac0d61b..1ef0074302c5 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.c
> @@ -63,7 +63,7 @@ void scaler_settings_calculation(struct
> dcn_bw_internal_vars *v)
> if (v->interlace_output[k] == 1.0) {
> v->v_ratio[k] = 2.0 * v->v_ratio[k];
> }
> - if ((v->underscan_output[k] == 1.0)) {
> + if (v->underscan_output[k] == 1.0) {
> v->h_ratio[k] = v->h_ratio[k] * v->under_scan_factor;
> v->v_ratio[k] = v->v_ratio[k] * v->under_scan_factor;
> }
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Don't re-enable CRC when CONFIG_DEBUG_FS isn't defined
On 2019-02-04 9:32 a.m., Nicholas Kazlauskas wrote:
> [Why]
> When CONFIG_DEBUG_FS isn't defined then amdgpu_dm_crtc_set_crc_source
> is NULL. This causes a compilation error since it's being called
> unconditionally.
>
> [How]
> Guard the call based on CONFIG_DEBUG_FS - CRC capture isn't supported
> without this.
>
> Cc: Leo Li
> Cc: Harry Wentland
> Fixes: 43a6a02eb355 ("drm/amd/display: Re-enable CRC capture following
> modeset")
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a2453900e15a..cacb8fe5a1ad 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5284,9 +5284,11 @@ static void amdgpu_dm_atomic_commit_tail(struct
> drm_atomic_state *state)
>
> manage_dm_interrupts(adev, acrtc, true);
>
> +#ifdef CONFIG_DEBUG_FS
> /* The stream has changed so CRC capture needs to re-enabled. */
> if (dm_new_crtc_state->crc_enabled)
> amdgpu_dm_crtc_set_crc_source(crtc, "auto");
> +#endif
> }
>
> /* update planes when needed per crtc*/
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Use context parameters to enable FBC
On 2019-02-04 4:20 a.m., S, Shirish wrote: > [What] > FBC fails to get enabled when switched between LINEAR(console/VT) > and non-LINEAR(GUI) based rendering due to default value of > tiling info stored in the current_state which is used for deciding > whether or not to turn FBC on or off. > > [How] > Use context structure's tiling information which is coherant with > the screen updates. > > Signed-off-by: Shirish S > --- > drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c > b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c > index db0ef41..fd7cd5b 100644 > --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c > +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c > @@ -2535,7 +2535,7 @@ static void dce110_apply_ctx_for_surface( > } > > if (dc->fbc_compressor) > - enable_fbc(dc, dc->current_state); > + enable_fbc(dc, context); Looks good, but I'd want Roma's RB. Acked-by: Harry Wentland Harry > } > > static void dce110_power_down_fe(struct dc *dc, struct pipe_ctx *pipe_ctx) > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 01/35] drm/amd/display: Use udelay when waiting between aux retries
On 2019-02-01 5:55 p.m., sylvain.bertr...@gmail.com wrote: > On Fri, Feb 01, 2019 at 09:20:56PM +0000, Wentland, Harry wrote: >> DRM's AUX code uses usleep_range in drm_dp_dpcd_access. > > My bad, forgot about the usleep_range switch. That said AUX_RETRY_INTERVAL is > 500 us, with a usleep_range top bound of 600 us. > > Then, it would mean DC DP timeout retries would happen after ~1ms, and drm > ~600us. Additionaly, it seems that the number of retries are 3 in drm code and > 7 in DC code. > DRM actually bumped this to 32 due to an issue with a Dell 4k display. > I may be wrong, but it seems DC code is much more "insisting" on auxchannel > (edid retrieval) and much more forgiving on monitor ability to timeout in > time (~1ms). > > If I did read the code the right way, it may be more reasonable to have > similar > behavior in drm code than in DC code, right? > It depends. I wouldn't call one or the other more correct. I seem to remember that the DP spec is quite vague on these retries but I could be mistaken. Since our driver hasn't show any problems with the DRM code and I believe others (such as i915) also pass DP compliance without issues I wouldn't proactively change this. Harry ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 01/35] drm/amd/display: Use udelay when waiting between aux retries
On 2019-02-01 3:47 p.m., sylvain.bertr...@gmail.com wrote: > On Fri, Feb 01, 2019 at 08:08:30PM +, sylvain.bertr...@gmail.com wrote: >> Do you mean non-DC displayport related code is already using udelay instead >> of msleep on linux? > > I grep-ed amdgpu displayport atombios code, got udelay(400) only. > Did the same on drm *_dp_* files, got similar udelays with only a very slow > msleep (which seems justified there). > > But I did not get any udelays with the range of 1ms for "retries". Maybe it > would be a good idea to a similar delay on non-DC displayport code? That would > give more time to "slow" displayort monitors to timeout on their side. > DRM's AUX code uses usleep_range in drm_dp_dpcd_access. Harry ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 01/35] drm/amd/display: Use udelay when waiting between aux retries
On 2019-02-01 12:31 p.m., sylvain.bertr...@gmail.com wrote: > On Fri, Feb 01, 2019 at 10:28:13AM -0500, Bhawanpreet Lakha wrote: >> From: John Barberiz >> [How] >> msleep is inaccurate for small values. Used udelay >> instead for accuracy. > > Hi, > > Should it be the case for non-DC displayport code too? > I don't think we're actually using this code on Linux. It's part of the shared codebase with Windows. Apparently there msleep would often sleep longer than 1ms. drm_dp_dpcd_access already has a tighter bound on the sleep between retries (500-600 us), so I imagine we're fine there. Harry > regards, > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines
On 2019-01-29 1:56 p.m., Guenter Roeck wrote: > On Tue, Jan 29, 2019 at 10:30:31AM -0500, Alex Deucher wrote: >> On Fri, Jan 25, 2019 at 10:29 AM Wentland, Harry >> wrote: >>> >>> On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote: >>>> arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The >>>> AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn >>>> on SSE2 to support emitting double precision floating point instructions >>>> rather than calls to non-existent (usually available from gcc_s or >>>> compiler_rt) floating point helper routines. >>>> >>>> Link: >>>> https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html >>>> Link: https://github.com/ClangBuiltLinux/linux/issues/327 >>>> Cc: sta...@vger.kernel.org # 4.19 >>>> Reported-by: S, Shirish >>>> Reported-by: Matthias Kaehlcke >>>> Suggested-by: James Y Knight >>>> Suggested-by: Nathan Chancellor >>>> Signed-off-by: Nick Desaulniers >>>> Tested-by: Guenter Roeck >>> >>> Reviewed-by: Harry Wentland >>> >>> and applied. >>> >> >> This patch causes a segfault: >> https://bugs.freedesktop.org/show_bug.cgi?id=109487 >> >> Any ideas? >> > > Set -msse2 only for clang ? I suspect, though, that this might only > solve the compile problem. If I understand correctly, the first > warning in the log is due to BREAK_TO_DEBUGGER(), suggesting that > something is seriously wrong. Maybe enabling sse2 results in different > results from floating point operations. > > Unfortunately I don't have a system with the affected GPU, > so I can't run any tests on real hardware. Unless someone can test > with real hardware, I think we have no choice but to revert the > patch. > Might be a good idea. Even though, best to revert for now until we understand what's going on. It seems like people at AMD building with gcc 5.4 are fine, but those using gcc 7.3 or 8.2 experience the crash. Harry > Guenter > >> Alex >> >>> Harry >>> >>>> --- >>>> drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- >>>> drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +- >>>> 2 files changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile >>>> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile >>>> index 95f332ee3e7e..dc85a3c088af 100644 >>>> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile >>>> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile >>>> @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) >>>> cc_stack_align := -mstack-alignment=16 >>>> endif >>>> >>>> -calcs_ccflags := -mhard-float -msse $(cc_stack_align) >>>> +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) >>>> >>>> CFLAGS_dcn_calcs.o := $(calcs_ccflags) >>>> CFLAGS_dcn_calc_auto.o := $(calcs_ccflags) >>>> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile >>>> b/drivers/gpu/drm/amd/display/dc/dml/Makefile >>>> index d97ca6528f9d..33c7d7588712 100644 >>>> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile >>>> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile >>>> @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) >>>> cc_stack_align := -mstack-alignment=16 >>>> endif >>>> >>>> -dml_ccflags := -mhard-float -msse $(cc_stack_align) >>>> +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) >>>> >>>> CFLAGS_display_mode_lib.o := $(dml_ccflags) >>>> CFLAGS_display_pipe_clocks.o := $(dml_ccflags) >>>> >>> ___ >>> amd-gfx mailing list >>> amd-gfx@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"
On 2019-01-29 11:57 a.m., Alex Deucher wrote: > This reverts commit 10117450735c7a7c0858095fb46a860e7037cb9a. > > Causes a crash. > > Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109487 > Signed-off-by: Alex Deucher > Cc: sta...@vger.kernel.org # 4.19 Thanks for finding and reverting. Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- > drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > index dc85a3c088af..95f332ee3e7e 100644 > --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > cc_stack_align := -mstack-alignment=16 > endif > > -calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > +calcs_ccflags := -mhard-float -msse $(cc_stack_align) > > CFLAGS_dcn_calcs.o := $(calcs_ccflags) > CFLAGS_dcn_calc_auto.o := $(calcs_ccflags) > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index 33c7d7588712..d97ca6528f9d 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > cc_stack_align := -mstack-alignment=16 > endif > > -dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > +dml_ccflags := -mhard-float -msse $(cc_stack_align) > > CFLAGS_display_mode_lib.o := $(dml_ccflags) > CFLAGS_display_pipe_clocks.o := $(dml_ccflags) > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display - Don't leak memory when updating streams
On 2019-01-28 9:00 a.m., Nicholas Kazlauskas wrote:
> [Why]
> The flip and full structures were allocated but never freed.
>
> [How]
> Free them at the end of the function. There's a small behavioral
> change here with the function returning early if the allocation fails
> but we wouldn't should be doing anything in that case anyway.
>
> Fixes: c00e0cc0fdc0 ("drm/amd/display: Call into DC once per multiplane flip")
> Fixes: ea39594e0855 ("drm/amd/display: Perform plane updates only when
> needed")
>
> Cc: Michel Dänzer
> Cc: Leo Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e551183784fb..78c89da47a33 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4760,8 +4760,10 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
> flip = kzalloc(sizeof(*flip), GFP_KERNEL);
> full = kzalloc(sizeof(*full), GFP_KERNEL);
>
> - if (!flip || !full)
> + if (!flip || !full) {
> dm_error("Failed to allocate update bundles\n");
> + goto cleanup;
> + }
>
> /* update planes when needed */
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) {
> @@ -4985,6 +4987,10 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
>dc_state);
> mutex_unlock(>dc_lock);
> }
> +
> +cleanup:
> + kfree(flip);
> + kfree(full);
> }
>
> /*
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines
On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote: > arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The > AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn > on SSE2 to support emitting double precision floating point instructions > rather than calls to non-existent (usually available from gcc_s or > compiler_rt) floating point helper routines. > > Link: https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html > Link: https://github.com/ClangBuiltLinux/linux/issues/327 > Cc: sta...@vger.kernel.org # 4.19 > Reported-by: S, Shirish > Reported-by: Matthias Kaehlcke > Suggested-by: James Y Knight > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers > Tested-by: Guenter Roeck Reviewed-by: Harry Wentland and applied. Harry > --- > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- > drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > index 95f332ee3e7e..dc85a3c088af 100644 > --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > cc_stack_align := -mstack-alignment=16 > endif > > -calcs_ccflags := -mhard-float -msse $(cc_stack_align) > +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > CFLAGS_dcn_calcs.o := $(calcs_ccflags) > CFLAGS_dcn_calc_auto.o := $(calcs_ccflags) > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index d97ca6528f9d..33c7d7588712 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > cc_stack_align := -mstack-alignment=16 > endif > > -dml_ccflags := -mhard-float -msse $(cc_stack_align) > +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > CFLAGS_display_mode_lib.o := $(dml_ccflags) > CFLAGS_display_pipe_clocks.o := $(dml_ccflags) > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [Linux-v4.18-rc6] modpost-errors when compiling with clang-7 and CONFIG_DRM_AMDGPU=m
On 2019-01-25 3:25 a.m., Koenig, Christian wrote: > Am 25.01.19 um 08:42 schrieb Sedat Dilek: >> [ CC Nick D. ] >> >> Hi Christian, >> >> Nick has posted a fix in [2]. >> Is that OK for you? > > I've seen that and yeah I'm perfectly fine with it, but Harry is the one > who needs to decide. > Looks good to me. Reviewed-by: Harry Wentland And applied. Harry > Christian. > >> >> I have also added the Link [1] in the ClangBuiltLinux issue tracker. >> >> Regards, >> - Sedat - >> >> [1] https://github.com/ClangBuiltLinux/linux/issues/327 >> [2] https://lkml.org/lkml/2019/1/24/1376 >> >> On Mon, Oct 22, 2018 at 10:42 AM Koenig, Christian >> wrote: >>> Am 22.10.18 um 10:40 schrieb Sedat Dilek: [SNIP] >> Am 29.07.2018 um 15:52 schrieb Sedat Dilek: >>> Hi, >>> >>> when compiling with clang-7 and CONFIG_DRM_AMDGPU=m I see the >>> following... >>> >>> if [ "" = "-pg" ]; then if [ arch/x86/boot/compressed/misc.o != >>> "scripts/mod/empty.o" ]; then ./scripts/recordmcount >>> "arch/x86/boot/compressed/misc.o"; fi; fi; >>> ERROR: "__addsf3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__subdf3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__gedf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__fixunssfsi" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__floatunsisf" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__unordsf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__gesf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__mulsf3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__truncdfsf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__ltsf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__muldf3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__divdf3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__eqsf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__floatsisf" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__ledf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__gtsf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__fixdfsi" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__floatunsidf" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__nesf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__adddf3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__extendsfdf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__fixunsdfsi" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__lesf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__ltdf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__floatsidf" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__subsf3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__gtdf2" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__fixsfsi" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__divsf3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> ERROR: "__floatdidf" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! >>> make[4]: *** [scripts/Makefile.modpost:92: __modpost] Error 1 >>> make[3]: *** [Makefile:1208: modules] Error 2 >>> make[3]: *** Waiting for unfinished jobs >>> >>> For now I have disabled CONFIG_DRM_AMDGPU=n. >>> >>> Do you need further informations? >>> Hi, any news on this issue? >>> Unfortunately not as far as I know. Harray any time line when we could >>> fix that? >>> >>> Thanks, >>> Christian. >>> With Linux v4.19 final I am still building with CONFIG_DRM_AMDGPU=n. Thanks in advance. Regards, - Sedat - > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Expose connector VRR range via debugfs
On 2019-01-24 12:41 p.m., Christian König wrote:
> Am 24.01.19 um 18:06 schrieb Nicholas Kazlauskas:
>> [Why]
>> It's useful to know the min and max vrr range for IGT testing.
>>
>> [How]
>> Expose the min and max vfreq for the connector via a debugfs file
>> on the connector, "vrr_range".
>>
>> Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
>>
>> Cc: Harry Wentland
>> Cc: Leo Li
>> Signed-off-by: Nicholas Kazlauskas
>
> Oh, nice that is indeed useful. Acked-by: Christian König
>
>
FYI, IGT test case making use of this:
https://patchwork.freedesktop.org/patch/275982/
Reviewed-by: Harry Wentland
Harry
>> ---
>> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 22 ++-
>> 1 file changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>> index cca3e16cda4f..4a55cde027cf 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
>> @@ -671,6 +671,25 @@ static ssize_t dp_phy_test_pattern_debugfs_write(struct
>> file *f, const char __us
>> return bytes_from_user;
>> }
>> +/*
>> + * Returns the min and max vrr vfreq through the connector's debugfs file.
>> + * Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
>> + */
>> +static int vrr_range_show(struct seq_file *m, void *data)
>> +{
>> + struct drm_connector *connector = m->private;
>> + struct amdgpu_dm_connector *aconnector =
>> to_amdgpu_dm_connector(connector);
>> +
>> + if (connector->status != connector_status_connected)
>> + return -ENODEV;
>> +
>> + seq_printf(m, "Min: %u\n", (unsigned int)aconnector->min_vfreq);
>> + seq_printf(m, "Max: %u\n", (unsigned int)aconnector->max_vfreq);
>> +
>> + return 0;
>> +}
>> +DEFINE_SHOW_ATTRIBUTE(vrr_range);
>> +
>> static const struct file_operations dp_link_settings_debugfs_fops = {
>> .owner = THIS_MODULE,
>> .read = dp_link_settings_read,
>> @@ -697,7 +716,8 @@ static const struct {
>> } dp_debugfs_entries[] = {
>> {"link_settings", _link_settings_debugfs_fops},
>> {"phy_settings", _phy_settings_debugfs_fop},
>> - {"test_pattern", _phy_test_pattern_fops}
>> + {"test_pattern", _phy_test_pattern_fops},
>> + {"vrr_range", _range_fops}
>> };
>> int connector_debugfs_init(struct amdgpu_dm_connector *connector)
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v4 00/16] MST refcounting/atomic helpers cleanup
On 2019-01-04 7:14 p.m., Lyude Paul wrote: > This is the series I've been working on for a while now to get all of > the atomic DRM drivers in the tree to use the atomic MST helpers, and to > make the atomic MST helpers actually idempotent. Turns out it's a lot > more difficult to do that without also fixing how port and branch device > refcounting works so that it actually makes sense, since the current > upstream implementation requires a ton of magic in the atomic helpers to > work around properly and in many situations just plain doesn't work as > intended. > > There's still more cleanup that can be done, but I think this is a good > place to start off for now :). > > This version just contains some changes that I forgot to make that had > been requested much earlier, mainly in regards to the atomic checking > code I added to i915 and nouveau (but not the helpers). > > Also, per-request I've made a gitlab branch available for this: > > https://gitlab.freedesktop.org/lyudess/linux/commits/wip/mst-dual-kref-start-v4 > > Lyude Paul (16): > drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and > friends > drm/dp_mst: Introduce new refcounting scheme for mstbs and ports > drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref > fails > drm/dp_mst: Stop releasing VCPI when removing ports from topology > drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs > drm/i915: Keep malloc references to MST ports > drm/amdgpu/display: Keep malloc ref to MST port > drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() > drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() > drm/nouveau: Keep malloc references to MST ports > drm/nouveau: Stop unsetting mstc->port, use malloc refs > drm/nouveau: Grab payload lock in nv50_msto_payload() > drm/dp_mst: Add some atomic state iterator macros > drm/dp_mst: Start tracking per-port VCPI allocations > drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() > drm/nouveau: Use atomic VCPI helpers for MST > Somehow I left my RB on v2 for a while. Either way patches 2-5, and 7 are Reviewed-by: Harry Wentland Haven't had a chance to take a look at 13-15 but noticed the "Changes since v" mention versions that either aren't on the mailing list or don't line up with the patch versioning. Harry > .../gpu/dp-mst/topology-figure-1.dot | 52 + > .../gpu/dp-mst/topology-figure-2.dot | 56 ++ > .../gpu/dp-mst/topology-figure-3.dot | 59 ++ > Documentation/gpu/drm-kms-helpers.rst | 26 +- > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 11 +- > drivers/gpu/drm/drm_dp_mst_topology.c | 938 ++ > drivers/gpu/drm/i915/intel_connector.c| 4 + > drivers/gpu/drm/i915/intel_display.c | 4 + > drivers/gpu/drm/i915/intel_dp_mst.c | 55 +- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 96 +- > include/drm/drm_dp_mst_helper.h | 151 ++- > 11 files changed, 1203 insertions(+), 249 deletions(-) > create mode 100644 Documentation/gpu/dp-mst/topology-figure-1.dot > create mode 100644 Documentation/gpu/dp-mst/topology-figure-2.dot > create mode 100644 Documentation/gpu/dp-mst/topology-figure-3.dot > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 07/16] drm/amdgpu/display: Keep malloc ref to MST port
On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> Just like i915 and nouveau, it's a good idea for us to hold a malloc
> reference to the port here so that we never pass a freed pointer to any
> of the DP MST helper functions.
>
> Also, we stop unsetting aconnector->port in
> dm_dp_destroy_mst_connector(). There's literally no point to that
> assignment that I can see anyway.
>
> Signed-off-by: Lyude Paul
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by: Harry Wentland
Harry
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 5e7ca1f3a8d1..24632727e127 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -191,6 +191,7 @@ dm_dp_mst_connector_destroy(struct drm_connector
> *connector)
> drm_encoder_cleanup(_encoder->base);
> kfree(amdgpu_encoder);
> drm_connector_cleanup(connector);
> + drm_dp_mst_put_port_malloc(amdgpu_dm_connector->port);
> kfree(amdgpu_dm_connector);
> }
>
> @@ -363,7 +364,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
> *mgr,
> amdgpu_dm_connector_funcs_reset(connector);
>
> DRM_INFO("DM_MST: added connector: %p [id: %d] [master: %p]\n",
> - aconnector, connector->base.id, aconnector->mst_port);
> + aconnector, connector->base.id, aconnector->mst_port);
> +
> + drm_dp_mst_get_port_malloc(port);
>
> DRM_DEBUG_KMS(":%d\n", connector->base.id);
>
> @@ -379,12 +382,12 @@ static void dm_dp_destroy_mst_connector(struct
> drm_dp_mst_topology_mgr *mgr,
> struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(connector);
>
> DRM_INFO("DM_MST: Disabling connector: %p [id: %d] [master: %p]\n",
> - aconnector, connector->base.id,
> aconnector->mst_port);
> + aconnector, connector->base.id, aconnector->mst_port);
>
> - aconnector->port = NULL;
> if (aconnector->dc_sink) {
> amdgpu_dm_update_freesync_caps(connector, NULL);
> - dc_link_remove_remote_sink(aconnector->dc_link,
> aconnector->dc_sink);
> + dc_link_remove_remote_sink(aconnector->dc_link,
> +aconnector->dc_sink);
> dc_sink_release(aconnector->dc_sink);
> aconnector->dc_sink = NULL;
> }
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 05/16] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> Up until now, freeing payloads on remote MST hubs that just had ports
> removed has almost never worked because we've been relying on port
> validation in order to stop us from accessing ports that have already
> been freed from memory, but ports which need their payloads released due
> to being removed will never be a valid part of the topology after
> they've been removed.
>
> Since we've introduced malloc refs, we can replace all of the validation
> logic in payload helpers which are used for deallocation with some
> well-placed malloc krefs. This ensures that regardless of whether or not
> the ports are still valid and in the topology, any port which has an
> allocated payload will remain allocated in memory until it's payloads
> have been removed - finally allowing us to actually release said
> payloads correctly.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 54 +++
> 1 file changed, 30 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ef8637f37564..11dd3ede7b7d 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2100,10 +2100,6 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
> u8 sinks[DRM_DP_MAX_SDP_STREAMS];
> int i;
>
> - port = drm_dp_mst_topology_get_port_validated(mgr, port);
> - if (!port)
> - return -EINVAL;
> -
> port_num = port->port_num;
> mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
> if (!mstb) {
> @@ -2111,10 +2107,8 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
> port->parent,
> _num);
>
> - if (!mstb) {
> - drm_dp_mst_topology_put_port(port);
> + if (!mstb)
> return -EINVAL;
> - }
> }
>
> txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> @@ -2151,7 +2145,6 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
> kfree(txmsg);
> fail_put:
> drm_dp_mst_topology_put_mstb(mstb);
> - drm_dp_mst_topology_put_port(port);
> return ret;
> }
>
> @@ -2256,15 +2249,16 @@ static int drm_dp_destroy_payload_step2(struct
> drm_dp_mst_topology_mgr *mgr,
> */
> int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
> {
> - int i, j;
> - int cur_slots = 1;
> struct drm_dp_payload req_payload;
> struct drm_dp_mst_port *port;
> + int i, j;
> + int cur_slots = 1;
>
> mutex_lock(>payload_lock);
> for (i = 0; i < mgr->max_payloads; i++) {
> struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
> struct drm_dp_payload *payload = >payloads[i];
> + bool put_port = false;
>
> /* solve the current payloads - compare to the hw ones
> - update the hw view */
> @@ -2272,12 +2266,20 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> if (vcpi) {
> port = container_of(vcpi, struct drm_dp_mst_port,
> vcpi);
> - port = drm_dp_mst_topology_get_port_validated(mgr,
> - port);
> - if (!port) {
> - mutex_unlock(>payload_lock);
> - return -EINVAL;
> +
> + /* Validated ports don't matter if we're releasing
> + * VCPI
> + */
> + if (vcpi->num_slots) {
> + port = drm_dp_mst_topology_get_port_validated(
> + mgr, port);
> + if (!port) {
> + mutex_unlock(>payload_lock);
> + return -EINVAL;
> + }
> + put_port = true;
> }
> +
> req_payload.num_slots = vcpi->num_slots;
> req_payload.vcpi = vcpi->vcpi;
> } else {
> @@ -2309,7 +231
Re: [PATCH v2 04/16] drm/dp_mst: Stop releasing VCPI when removing ports from topology
On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> This has never actually worked, and isn't needed anyway: the driver's
> always going to try to deallocate VCPI when it tears down the display
> that the VCPI belongs to.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 356a95aba2d8..ef8637f37564 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1175,8 +1175,6 @@ static void drm_dp_destroy_port(struct kref *kref)
> struct drm_dp_mst_topology_mgr *mgr = port->mgr;
>
> if (!port->input) {
> - port->vcpi.num_slots = 0;
> -
> kfree(port->cached_edid);
>
> /*
> @@ -3491,12 +3489,6 @@ static void drm_dp_destroy_connector_work(struct
> work_struct *work)
> drm_dp_port_teardown_pdt(port, port->pdt);
> port->pdt = DP_PEER_DEVICE_NONE;
>
> - if (!port->input && port->vcpi.vcpi > 0) {
> - drm_dp_mst_reset_vcpi_slots(mgr, port);
> - drm_dp_update_payload_part1(mgr);
> - drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
> - }
> -
> drm_dp_mst_put_port_malloc(port);
> send_hotplug = true;
> }
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 03/16] drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails
On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> While this isn't a complete fix, this will improve the reliability of
> drm_dp_get_last_connected_port_and_mstb() pretty significantly during
> hotplug events, since there's a chance that the in-memory topology tree
> may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
> is called and thus might end up causing our search to fail on an mstb
> whose topology refcount has reached 0, but has not yet been removed from
> it's parent.
>
> Ideally, we should further fix this problem by ensuring that we deal
> with the potential for racing with a hotplug event, which would look
> like this:
>
> * drm_dp_payload_send_msg() retrieves the last living relative of mstb
> with drm_dp_get_last_connected_port_and_mstb()
> * drm_dp_payload_send_msg() starts building payload message
> At the same time, mstb gets unplugged from the topology and is no
> longer the actual last living relative of the original mstb
> * drm_dp_payload_send_msg() tries sending the payload message, hub times
> out
> * Hub timed out, we give up and run away-resulting in the payload being
> leaked
>
> This could be fixed by restarting the
> drm_dp_get_last_connected_port_and_mstb() search whenever we get a
> timeout, sending the payload to the new mstb, then repeating until
> either the entire topology is removed from the system or
> drm_dp_get_last_connected_port_and_mstb() fails. But since the above
> race condition is not terribly likely, we'll address that in a later
> patch series once we've improved the recovery handling for VCPI
> allocations in the rest of the DP MST helpers.
>
> Signed-off-by: Lyude Paul
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 55 +--
> 1 file changed, 44 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index b380ada09e90..356a95aba2d8 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2043,25 +2043,50 @@ static struct drm_dp_mst_port
> *drm_dp_get_last_connected_port_to_mstb(struct drm
> return
> drm_dp_get_last_connected_port_to_mstb(mstb->port_parent->parent);
> }
>
> -static struct drm_dp_mst_branch
> *drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
> - struct
> drm_dp_mst_branch *mstb,
> - int
> *port_num)
> +/**
> + * drm_dp_get_last_connected_port_and_mstb() - Find the last living relatives
> + * in a topology of a given branch device
> + * @mgr: The topology manager to use
> + * @mstb: The disconnected branch device
> + * @port_num: Where to store the number of the last connected port
> + *
> + * Searches upwards in the topology starting from @mstb to try to find the
> + * closest available parent of @mstb that's still connected to the rest of
> the
> + * topology. This can be used in order to perform operations like releasing
> + * payloads, where the branch device which owned the payload may no longer be
> + * around and thus would require that the payload on the last living relative
> + * be freed instead.
> + *
> + * Returns:
> + * The last connected _dp_mst_branch in the topology that was a parent of
> + * @mstb, if there is one.
> + */
> +static struct drm_dp_mst_branch *
> +drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_mst_branch *mstb,
> + int *port_num)
> {
> struct drm_dp_mst_branch *rmstb = NULL;
> struct drm_dp_mst_port *found_port;
> +
> mutex_lock(>lock);
> - if (mgr->mst_primary) {
> + if (!mgr->mst_primary)
> + goto out;
> +
> + do {
> found_port = drm_dp_get_last_connected_port_to_mstb(mstb);
> + if (!found_port)
> + break;
>
> - if (found_port) {
> + if (drm_dp_mst_topology_try_get_mstb(found_port->parent)) {
> rmstb = found_port->parent;
> - if (drm_dp_mst_topology_try_get_mstb(rmstb)) {
> - *port_num = found_port->port_num;
> - } else {
> - rmstb = NULL;
> - }
> + *port_num = found_port->port_num;
> + } el
Re: [PATCH v4 02/16] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
On 2019-01-04 7:14 p.m., Lyude Paul wrote:
> The current way of handling refcounting in the DP MST helpers is really
> confusing and probably just plain wrong because it's been hacked up many
> times over the years without anyone actually going over the code and
> seeing if things could be simplified.
>
> To the best of my understanding, the current scheme works like this:
> drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
> this refcount hits 0 for either of the two, they're removed from the
> topology state, but not immediately freed. Both ports and branch devices
> will reinitialize their kref once it's hit 0 before actually destroying
> themselves. The intended purpose behind this is so that we can avoid
> problems like not being able to free a remote payload that might still
> be active, due to us having removed all of the port/branch device
> structures in memory, as per:
>
> commit 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
>
> Which may have worked, but then it caused use-after-free errors. Being
> new to MST at the time, I tried fixing it;
>
> commit 263efde31f97 ("drm/dp/mst: Get validated port ref in
> drm_dp_update_payload_part1()")
>
> But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs
> are validated in almost every DP MST helper function. Simply put, this
> means we go through the topology and try to see if the given
> drm_dp_mst_branch or drm_dp_mst_port is still attached to something
> before trying to use it in order to avoid dereferencing freed memory
> (something that has happened a LOT in the past with this library).
> Because of this it doesn't actually matter whether or not we keep keep
> the ports and branches around in memory as that's not enough, because
> any function that validates the branches and ports passed to it will
> still reject them anyway since they're no longer in the topology
> structure. So, use-after-free errors were fixed but payload deallocation
> was completely broken.
>
> Two years later, AMD informed me about this issue and I attempted to
> come up with a temporary fix, pending a long-overdue cleanup of this
> library:
>
> commit c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction,
> just ref")
>
> But then that introduced use-after-free errors, so I quickly reverted
> it:
>
> commit 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during
> destruction, just ref"")
>
> And in the process, learned that there is just no simple fix for this:
> the design is just broken. Unfortuntely, the usage of these helpers are
> quite broken as well. Some drivers like i915 have been smart enough to
> avoid accessing any kind of information from MST port structures, but
> others like nouveau have assumed, understandably so, that
> drm_dp_mst_port structures are normal and can just be accessed at any
> time without worrying about use-after-free errors.
>
> After a lot of discussion, me and Daniel Vetter came up with a better
> idea to replace all of this.
>
> To summarize, since this is documented far more indepth in the
> documentation this patch introduces, we make it so that drm_dp_mst_port
> and drm_dp_mst_branch structures have two different classes of
> refcounts: topology_kref, and malloc_kref. topology_kref corresponds to
> the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
> given topology. Once it hits zero, any associated connectors are removed
> and the branch or port can no longer be validated. malloc_kref
> corresponds to the lifetime of the memory allocation for the actual
> structure, and will always be non-zero so long as the topology_kref is
> non-zero. This gives us a way to allow callers to hold onto port and
> branch device structures past their topology lifetime, and dramatically
> simplifies the lifetimes of both structures. This also finally fixes the
> port deallocation problem, properly.
>
> Additionally: since this now means that we can keep ports and branch
> devices allocated in memory for however long we need, we no longer need
> a significant amount of the port validation that we currently do.
>
> Additionally, there is one last scenario that this fixes, which couldn't
> have been fixed properly beforehand:
>
> - CPU1 unrefs port from topology (refcount 1->0)
> - CPU2 refs port in topology(refcount 0->1)
>
> Since we now can guarantee memory safety for ports and branches
> as-needed, we also can make our main reference counting functions fix
> this problem by using kref_get_unless_zero() internally so that topology
> refcounts can only ever reach 0 once.
>
> Changes since v2:
> * Fix commit message - checkpatch
> Changes since v1:
> * Remove forward declarations - danvet
> * Move "Branch device and port refcounting" section from documentation
> into kernel-doc comments - danvet
> * Export internal topology lifetime functions into their own section in
> the kernel-docs - danvet
> * s/@/&/g for struct
Re: [PATCH 0/3] drm/amdgpu: Fix suspend/resume issues with MST
On 2019-01-07 7:56 p.m., Lyude Paul wrote: > Fix the suspend/issues that Jerry Zuo found in amdgpu, and add some > compiler warnings for drivers ignoring the return code of > drm_dp_mst_topology_mgr_resume() to help ensure we don't need to fix > this again in the future for someone else's driver. > > Cc: Jerry Zuo With the small change Daniel mentioned this series is Reviewed-by: Harry Wentland Harry > > Lyude Paul (3): > drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume() > drm/amdgpu: Don't fail resume process if resuming atomic state fails > drm/dp_mst: Add __must_check to drm_dp_mst_topology_mgr_resume() > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 37 +-- > drivers/gpu/drm/drm_dp_mst_topology.c | 3 +- > include/drm/drm_dp_mst_helper.h | 3 +- > 3 files changed, 29 insertions(+), 14 deletions(-) > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Fix boolean expression in get_surf_rq_param
On 2019-01-03 2:48 p.m., Gustavo A. R. Silva wrote:
> Fix boolean expression by using logical AND operator '&&'
> instead of bitwise operator '&'.
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 6d04ee9dc101 ("drm/amd/display: Restructuring and cleaning up DML")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Harry Wentland
and applied.
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c
> b/drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c
> index c2037daa8e66..d341b69fdc1a 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c
> @@ -881,7 +881,7 @@ static void get_surf_rq_param(
> /* the dpte_group_bytes is reduced for the specific case of vertical
>* access of a tile surface that has dpte request of 8x1 ptes.
>*/
> - if (!surf_linear & (log2_dpte_req_height_ptes == 0) & surf_vert)
> /*reduced, in this case, will have page fault within a group */
> + if (!surf_linear && (log2_dpte_req_height_ptes == 0) && surf_vert)
> /*reduced, in this case, will have page fault within a group */
> rq_sizing_param->dpte_group_bytes = 512;
> else
> /*full size */
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Add below the range support for FreeSync
On 2018-12-05 8:40 a.m., Nicholas Kazlauskas wrote:
> [Why]
> When application flip-rate is below the minimum vrr refresh rate.
>
> Variable refresh rate monitors extend the front porch duration until
> flip or timeout occurs. For cases where the application flip-rate is
>
> When the flip-rate is below the minimum supported variable refresh rate
> range for the monitor the front porch wait will timeout and be
> frequently misaligned resulting in stuttering and/or flickering.
>
> The FreeSync module can still maintain a smooth and flicker free
> image when the monitor has a refresh rate range such that the maximum
> refresh > 2 * minimum refresh by utilizing low framerate compensation,
> "below the range".
>
> [How]
> Hook up the pre-flip and post-flip handlers from the FreeSync module.
> These adjust the minimum/maximum vrr range to duplicate frames
> when appropriate by tracking flip timestamps.
>
> Cc: Leo Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 79 ++-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
> 2 files changed, 62 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 23d61570df17..e2de064426fc 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -328,12 +328,29 @@ static void dm_crtc_high_irq(void *interrupt_params)
> struct common_irq_params *irq_params = interrupt_params;
> struct amdgpu_device *adev = irq_params->adev;
> struct amdgpu_crtc *acrtc;
> + struct dm_crtc_state *acrtc_state;
>
> acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src -
> IRQ_TYPE_VBLANK);
>
> if (acrtc) {
> drm_crtc_handle_vblank(>base);
> amdgpu_dm_crtc_handle_crc_irq(>base);
> +
> + acrtc_state = to_dm_crtc_state(acrtc->base.state);
> +
> + if (acrtc_state->stream &&
> + acrtc_state->vrr_params.supported &&
> + acrtc_state->freesync_config.state ==
> VRR_STATE_ACTIVE_VARIABLE) {
> + mod_freesync_handle_v_update(
> + adev->dm.freesync_module,
> + acrtc_state->stream,
> + _state->vrr_params);
> +
> + dc_stream_adjust_vmin_vmax(
> + adev->dm.dc,
> + acrtc_state->stream,
> + _state->vrr_params.adjust);
> + }
> }
> }
>
> @@ -3001,7 +3018,7 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
> dc_stream_retain(state->stream);
> }
>
> - state->adjust = cur->adjust;
> + state->vrr_params = cur->vrr_params;
> state->vrr_infopacket = cur->vrr_infopacket;
> state->abm_level = cur->abm_level;
> state->vrr_supported = cur->vrr_supported;
> @@ -4396,9 +4413,11 @@ struct dc_stream_status *dc_state_get_stream_status(
> static void update_freesync_state_on_stream(
> struct amdgpu_display_manager *dm,
> struct dm_crtc_state *new_crtc_state,
> - struct dc_stream_state *new_stream)
> + struct dc_stream_state *new_stream,
> + struct dc_plane_state *surface,
> + u32 flip_timestamp_in_us)
> {
> - struct mod_vrr_params vrr = {0};
> + struct mod_vrr_params vrr_params = new_crtc_state->vrr_params;
> struct dc_info_packet vrr_infopacket = {0};
> struct mod_freesync_config config = new_crtc_state->freesync_config;
>
> @@ -4425,43 +,52 @@ static void update_freesync_state_on_stream(
>
> mod_freesync_build_vrr_params(dm->freesync_module,
> new_stream,
> - , );
> + , _params);
> +
> + if (surface) {
> + mod_freesync_handle_preflip(
> + dm->freesync_module,
> + surface,
> + new_stream,
> + flip_timestamp_in_us,
> + _params);
> + }
>
> mod_freesync_build_vrr_infopacket(
> dm->freesync_module,
> new_stream,
> - ,
> + _params,
> PACKET_TYPE_VRR,
> TRANSFER_FUNC_UNKNOWN,
>
Re: [PATCH] drm/amd/display: Set requested plane state DCC params for GFX9
On 2019-01-02 3:15 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Hardware support for Delta Color Compression (DCC) decompression is
> available in DC for GFX9 but there's no way for userspace to enable
> the feature.
>
> Enabling the feature can provide improved GFX performance and
> power savings in many situations.
>
> [How]
> The GFX9 DCC parameters are passed to amdgpu_dm from AMDGPU via the
> amdgpu_bo tiling_flags. The plane capability is queried and the
> parameters are set accordingly.
>
> The DCC address is given via a 256 byte aligned offset on the
> framebuffer address. The DCC address is updated whenever the buffer
> address changes.
>
> Cc: Marek Olšák
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 90 ++-
> 1 file changed, 88 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 306540c36616..4839d2dc 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2356,6 +2356,68 @@ static int get_fb_info(const struct amdgpu_framebuffer
> *amdgpu_fb,
> return r;
> }
>
> +static inline uint64_t get_dcc_address(uint64_t address, uint64_t
> tiling_flags)
> +{
> + uint32_t offset = AMDGPU_TILING_GET(tiling_flags, DCC_OFFSET_256B);
> +
> + return offset ? (address + offset * 256) : 0;
> +}
> +
> +static bool fill_plane_dcc_attributes(struct amdgpu_device *adev,
> + const struct amdgpu_framebuffer *afb,
> + struct dc_plane_state *plane_state,
> + uint64_t info)
> +{
> + struct dc *dc = adev->dm.dc;
> + struct dc_dcc_surface_param input = {0};
> + struct dc_surface_dcc_cap output = {0};
> + uint32_t offset = AMDGPU_TILING_GET(info, DCC_OFFSET_256B);
> + uint32_t i64b = AMDGPU_TILING_GET(info, DCC_INDEPENDENT_64B) != 0;
> + uint64_t dcc_address;
> +
> + if (!offset)
> + return false;
> +
> + if (!dc->cap_funcs.get_dcc_compression_cap)
> + return false;
> +
> + input.format = plane_state->format;
> + input.surface_size.width =
> + plane_state->plane_size.grph.surface_size.width;
> + input.surface_size.height =
> + plane_state->plane_size.grph.surface_size.height;
> + input.swizzle_mode = plane_state->tiling_info.gfx9.swizzle;
> +
> + if (plane_state->rotation == ROTATION_ANGLE_0 ||
> + plane_state->rotation == ROTATION_ANGLE_180)
> + input.scan = SCAN_DIRECTION_HORIZONTAL;
> + else if (plane_state->rotation == ROTATION_ANGLE_90 ||
> + plane_state->rotation == ROTATION_ANGLE_270)
> + input.scan = SCAN_DIRECTION_VERTICAL;
> +
> + if (!dc->cap_funcs.get_dcc_compression_cap(dc, , ))
> + return false;
> +
> + if (!output.capable)
> + return false;
> +
> + if (i64b == 0 && output.grph.rgb.independent_64b_blks != 0)
> + return false;
> +
> + plane_state->dcc.enable = 1;
> + plane_state->dcc.grph.meta_pitch =
> + AMDGPU_TILING_GET(info, DCC_PITCH_MAX) + 1;
> + plane_state->dcc.grph.independent_64b_blks = i64b;
> +
> + dcc_address = get_dcc_address(afb->address, info);
> + plane_state->address.grph.meta_addr.low_part =
> + lower_32_bits(dcc_address);
> + plane_state->address.grph.meta_addr.high_part =
> + upper_32_bits(dcc_address);
> +
> + return true;
> +}
> +
> static int fill_plane_attributes_from_fb(struct amdgpu_device *adev,
>struct dc_plane_state *plane_state,
>const struct amdgpu_framebuffer
> *amdgpu_fb)
> @@ -2408,6 +2470,10 @@ static int fill_plane_attributes_from_fb(struct
> amdgpu_device *adev,
> return -EINVAL;
> }
>
> + memset(_state->address, 0, sizeof(plane_state->address));
> + memset(_state->tiling_info, 0, sizeof(plane_state->tiling_info));
> + memset(_state->dcc, 0, sizeof(plane_state->dcc));
> +
> if (plane_state->format < SURFACE_PIXEL_FORMAT_VIDEO_BEGIN) {
> plane_state->address.type = PLN_ADDR_TYPE_GRAPHICS;
> plane_state->plane_size.grph.surface_size.x = 0;
> @@ -2439,8 +2505,6 @@ static int fill_plane_attributes_from_fb(struct
> amdg
Re: [PATCH] drm/amd/display: Fix 64-bit division for 32-bit builds
On 2018-12-19 3:28 p.m., sunpeng...@amd.com wrote: > From: Ken Chalmers > > [Why] > 32-bit builds break when doing 64-bit division directly. > > [How] > Use the div_u64() function instead to perform the division. > > Fixes: > https://lists.freedesktop.org/archives/dri-devel/2018-December/201008.html > Signed-off-by: Ken Chalmers > Reviewed-by: Leo Li Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c > b/drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c > index 5c629ae..8b5ce55 100644 > --- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c > +++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c > @@ -94,7 +94,7 @@ static void program_pix_dur(struct timing_generator *tg, > uint32_t pix_clk_100hz) > if (pix_clk_100hz == 0) > return; > > - pix_dur = 100ull / pix_clk_100hz; > + pix_dur = div_u64(100ull, pix_clk_100hz); > > set_reg_field_value( > value, > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [WIP PATCH 02/15] drm/dp_mst: Refactor drm_dp_update_payload_part1()
On 2018-12-14 3:47 a.m., Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote:
>> There should be no functional changes here
>
> Would be good to explain what you did refactor here, instead of me trying
> to reconstruct it from the patch. Especially pre-coffee that helps :-)
I concur. Something like "use local variables to improve readability".
With that fixed this is
Reviewed-by: Harry Wentland
Harry
>>
>> Signed-off-by: Lyude Paul
>> Cc: Juston Li
>> ---
>> drivers/gpu/drm/drm_dp_mst_topology.c | 71 ---
>> 1 file changed, 42 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index 9b1b5c9b1fa0..2ab16c9e6243 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1879,39 +1879,48 @@ int drm_dp_update_payload_part1(struct
>> drm_dp_mst_topology_mgr *mgr)
>>
>> mutex_lock(>payload_lock);
>> for (i = 0; i < mgr->max_payloads; i++) {
>> +struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
>> +struct drm_dp_payload *payload = >payloads[i];
>> +
>> /* solve the current payloads - compare to the hw ones
>> - update the hw view */
>> req_payload.start_slot = cur_slots;
>> -if (mgr->proposed_vcpis[i]) {
>> -port = container_of(mgr->proposed_vcpis[i], struct
>> drm_dp_mst_port, vcpi);
>> +if (vcpi) {
>> +port = container_of(vcpi, struct drm_dp_mst_port,
>> +vcpi);
>> port = drm_dp_get_validated_port_ref(mgr, port);
>> if (!port) {
>> mutex_unlock(>payload_lock);
>> return -EINVAL;
>> }
>> -req_payload.num_slots =
>> mgr->proposed_vcpis[i]->num_slots;
>> -req_payload.vcpi = mgr->proposed_vcpis[i]->vcpi;
>> +req_payload.num_slots = vcpi->num_slots;
>> +req_payload.vcpi = vcpi->vcpi;
>> } else {
>> port = NULL;
>> req_payload.num_slots = 0;
>> }
>>
>> -mgr->payloads[i].start_slot = req_payload.start_slot;
>> +payload->start_slot = req_payload.start_slot;
>> /* work out what is required to happen with this payload */
>> -if (mgr->payloads[i].num_slots != req_payload.num_slots) {
>> +if (payload->num_slots != req_payload.num_slots) {
>>
>> /* need to push an update for this payload */
>> if (req_payload.num_slots) {
>> -drm_dp_create_payload_step1(mgr,
>> mgr->proposed_vcpis[i]->vcpi, _payload);
>> -mgr->payloads[i].num_slots =
>> req_payload.num_slots;
>> -mgr->payloads[i].vcpi = req_payload.vcpi;
>> -} else if (mgr->payloads[i].num_slots) {
>> -mgr->payloads[i].num_slots = 0;
>> -drm_dp_destroy_payload_step1(mgr, port,
>> mgr->payloads[i].vcpi, >payloads[i]);
>> -req_payload.payload_state =
>> mgr->payloads[i].payload_state;
>> -mgr->payloads[i].start_slot = 0;
>> +drm_dp_create_payload_step1(mgr, vcpi->vcpi,
>> +_payload);
>> +payload->num_slots = req_payload.num_slots;
>> +payload->vcpi = req_payload.vcpi;
>> +
>> +} else if (payload->num_slots) {
>> +payload->num_slots = 0;
>> +drm_dp_destroy_payload_step1(mgr, port,
>> + payload->vcpi,
>> + payload);
>> +req_payload.payload_state =
>> +payload->payload_state;
>> +payload->start_slot = 0;
>> }
>> -mgr->payloads[i].payload_state =
>> req_pa
Re: [WIP PATCH 01/15] drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1()
On 2018-12-14 3:42 a.m., Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:30PM -0500, Lyude Paul wrote:
>> There's no reason we need this, it's just confusing looking.
>>
>> Signed-off-by: Lyude Paul
>> Cc: Juston Li
>> ---
>> drivers/gpu/drm/drm_dp_mst_topology.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index ad0fb6d003be..9b1b5c9b1fa0 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1896,9 +1896,7 @@ int drm_dp_update_payload_part1(struct
>> drm_dp_mst_topology_mgr *mgr)
>> req_payload.num_slots = 0;
>> }
>>
>> -if (mgr->payloads[i].start_slot != req_payload.start_slot) {
>> -mgr->payloads[i].start_slot = req_payload.start_slot;
>> -}
>> + mgr->payloads[i].start_slot = req_payload.start_slot;
>
> Entertaining!
>
> Reviewed-by: Daniel Vetter
>
Reviewed-by: Harry Wentland
Harry
>> /* work out what is required to happen with this payload */
>> if (mgr->payloads[i].num_slots != req_payload.num_slots) {
>>
>> --
>> 2.19.2
>>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2] drm/amd/display: Add below the range support for FreeSync
On 2018-12-05 12:08 p.m., Nicholas Kazlauskas wrote:
> [Why]
> When the flip-rate is below the minimum supported variable refresh rate
> range for the monitor the front porch wait will timeout and be
> frequently misaligned resulting in stuttering and/or flickering.
>
> The FreeSync module can still maintain a smooth and flicker free
> image when the monitor has a refresh rate range such that the maximum
> refresh > 2 * minimum refresh by utilizing low framerate compensation,
> "below the range".
>
> [How]
> Hook up the pre-flip and post-flip handlers from the FreeSync module.
> These adjust the minimum/maximum vrr range to duplicate frames
> when appropriate by tracking flip timestamps.
>
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
> Acked-by: Leo Li
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 79 ++-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
> 2 files changed, 62 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 23d61570df17..e2de064426fc 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -328,12 +328,29 @@ static void dm_crtc_high_irq(void *interrupt_params)
> struct common_irq_params *irq_params = interrupt_params;
> struct amdgpu_device *adev = irq_params->adev;
> struct amdgpu_crtc *acrtc;
> + struct dm_crtc_state *acrtc_state;
>
> acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src -
> IRQ_TYPE_VBLANK);
>
> if (acrtc) {
> drm_crtc_handle_vblank(>base);
> amdgpu_dm_crtc_handle_crc_irq(>base);
> +
> + acrtc_state = to_dm_crtc_state(acrtc->base.state);
> +
> + if (acrtc_state->stream &&
> + acrtc_state->vrr_params.supported &&
> + acrtc_state->freesync_config.state ==
> VRR_STATE_ACTIVE_VARIABLE) {
> + mod_freesync_handle_v_update(
> + adev->dm.freesync_module,
> + acrtc_state->stream,
> + _state->vrr_params);
> +
> + dc_stream_adjust_vmin_vmax(
> + adev->dm.dc,
> + acrtc_state->stream,
> + _state->vrr_params.adjust);
> + }
> }
> }
>
> @@ -3001,7 +3018,7 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
> dc_stream_retain(state->stream);
> }
>
> - state->adjust = cur->adjust;
> + state->vrr_params = cur->vrr_params;
> state->vrr_infopacket = cur->vrr_infopacket;
> state->abm_level = cur->abm_level;
> state->vrr_supported = cur->vrr_supported;
> @@ -4396,9 +4413,11 @@ struct dc_stream_status *dc_state_get_stream_status(
> static void update_freesync_state_on_stream(
> struct amdgpu_display_manager *dm,
> struct dm_crtc_state *new_crtc_state,
> - struct dc_stream_state *new_stream)
> + struct dc_stream_state *new_stream,
> + struct dc_plane_state *surface,
> + u32 flip_timestamp_in_us)
> {
> - struct mod_vrr_params vrr = {0};
> + struct mod_vrr_params vrr_params = new_crtc_state->vrr_params;
> struct dc_info_packet vrr_infopacket = {0};
> struct mod_freesync_config config = new_crtc_state->freesync_config;
>
> @@ -4425,43 +,52 @@ static void update_freesync_state_on_stream(
>
> mod_freesync_build_vrr_params(dm->freesync_module,
> new_stream,
> - , );
> + , _params);
> +
> + if (surface) {
> + mod_freesync_handle_preflip(
> + dm->freesync_module,
> + surface,
> + new_stream,
> + flip_timestamp_in_us,
> + _params);
> + }
>
> mod_freesync_build_vrr_infopacket(
> dm->freesync_module,
> new_stream,
> - ,
> + _params,
> PACKET_TYPE_VRR,
> TRANSFER_FUNC_UNKNOWN,
> _infopacket);
>
> new_crtc_state->freesync_timing_changed =
> - (memcmp(_crtc_state->adjust,
> - ,
> - sizeof(vrr.adjust)) != 0);
> + (memcmp(_cr
Re: After Vega 56/64 GPU hang I unable reboot system
On 2018-12-15 4:42 a.m., Mikhail Gavrilov wrote: > On Sat, 15 Dec 2018 at 00:36, Wentland, Harry wrote: >> >> Looks like there's an error before this happens that might get us into this >> mess: >> >> [ 229.741741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, >> signaled seq=28686, emitted seq=28688 >> [ 229.741806] [drm] GPU recovery disabled. >> >> Harry > > Harry, Is this ever will be fixed? > That annoying `ring gfx timeout` still follow me on all machines with > Vega GPU more than year. > Just yesterday I blocked the computer and went to sleep, at the > morning I found out that I could not unlock the machine. > After connected via ssh I saw again in the kernel log > `[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled > seq=32778472, emitted seq=32778474` > It means that this bug may happens even it I doing nothing on my machine. > > Should we wait for any improvement in localization this bug? > Because I suppose message `[drm:amdgpu_job_timedout [amdgpu]] *ERROR* > ring gfx timeout, signaled seq=32778472, emitted seq=32778474` not > contain any useful info for fixing this bug. > I don't know much about ring gfx timeouts as my area of expertise revolves around the display side of things, not gfx. Alex, Christian, any ideas? Harry > Thanks. > > -- > Best Regards, > Mike Gavrilov. > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Skip fast cursor updates for fb changes
On 2018-12-14 12:26 p.m., Nicholas Kazlauskas wrote:
> [Why]
> The behavior of drm_atomic_helper_cleanup_planes differs depending on
> whether the commit was asynchronous or not. When it's called from
> amdgpu_dm_atomic_commit_tail during a typical atomic commit the
> plane state has been swapped so it calls cleanup_fb on the old plane
> state.
>
> However, in the asynchronous commit codepath the call to
> drm_atomic_helper_commit also calls dm_plane_helper_cleanup_fb after
> atomic_async_update has been called. Since the plane state is updated
> in place and has not been swapped the cleanup_fb call affects the new
> plane state.
>
> This results in a use after free for the given sequence:
>
> - Fast update, fb1 pin/ref, fb1 unpin/unref
> - Fast update, fb2 pin/ref, fb2 unpin/unref
> - Slow update, fb1 pin/ref, fb2 unpin/unref
> - Fast update, fb2 pin/ref -> use after free. bug
>
> [How]
> Disallow framebuffer changes in the fast path. Since this includes
> a NULL framebuffer, this means that only framebuffers that have
> been previously pin+ref at least once will be used, preventing a
> use after free.
>
> This has a significant throughput reduction for cursor updates where
> the framebuffer changes. For most desktop usage this isn't a problem,
> but it does introduce performance regressions for two specific IGT
> tests:
>
> - cursor-vs-flip-toggle
> - cursor-vs-flip-varying-size
>
> Cc: Leo Li
> Cc: Harry Wentland
> Cc: Michel Dänzer
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index d01315965af0..dc1eb9ec2c38 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3628,10 +3628,20 @@ static int dm_plane_atomic_check(struct drm_plane
> *plane,
> static int dm_plane_atomic_async_check(struct drm_plane *plane,
> struct drm_plane_state *new_plane_state)
> {
> + struct drm_plane_state *old_plane_state =
> + drm_atomic_get_old_plane_state(new_plane_state->state, plane);
> +
> /* Only support async updates on cursor planes. */
> if (plane->type != DRM_PLANE_TYPE_CURSOR)
> return -EINVAL;
>
> + /*
> + * DRM calls prepare_fb and cleanup_fb on new_plane_state for
> + * async commits so don't allow fb changes.
> + */
> + if (old_plane_state->fb != new_plane_state->fb)
> + return -EINVAL;
> +
> return 0;
> }
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: After Vega 56/64 GPU hang I unable reboot system
On 2018-12-04 5:18 p.m., Mikhail Gavrilov wrote: > Hi guys. > I having troubles when Vega GPU is hang I unable reboot system. > > Can somebody help me please. > > I tried enter follow commands: > # init 6 > # reboot > But no one of them having success. > > SysRq-W showing to us this: > Looks like there's an error before this happens that might get us into this mess: [ 229.741741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=28686, emitted seq=28688 [ 229.741806] [drm] GPU recovery disabled. Harry > [ 613.397629] sysrq: SysRq : Show Blocked State > [ 613.397638] taskPC stack pid father > [ 613.397729] kworker/u32:4 D12912 252 2 0x8000 > [ 613.397748] Workqueue: events_unbound commit_work [drm_kms_helper] > [ 613.397752] Call Trace: > [ 613.397764] ? __schedule+0x2f3/0xb90 > [ 613.397770] ? __lock_acquire+0x279/0x1650 > [ 613.397778] ? dma_fence_default_wait+0x242/0x330 > [ 613.397784] schedule+0x2f/0x90 > [ 613.397788] schedule_timeout+0x31c/0x4f0 > [ 613.397792] ? find_held_lock+0x34/0xa0 > [ 613.397796] ? find_held_lock+0x34/0xa0 > [ 613.397802] ? mark_held_locks+0x57/0x80 > [ 613.397807] ? _raw_spin_unlock_irqrestore+0x4b/0x60 > [ 613.397813] ? dma_fence_default_wait+0x242/0x330 > [ 613.397817] dma_fence_default_wait+0x26e/0x330 > [ 613.397822] ? dma_fence_release+0x120/0x120 > [ 613.397829] dma_fence_wait_timeout+0x182/0x200 > [ 613.397835] reservation_object_wait_timeout_rcu+0x236/0x4e0 > [ 613.397911] amdgpu_dm_do_flip+0x112/0x380 [amdgpu] > [ 613.397993] amdgpu_dm_atomic_commit_tail+0x6d0/0xd30 [amdgpu] > [ 613.398001] ? _raw_spin_unlock_irq+0x29/0x40 > [ 613.398005] ? wait_for_completion_timeout+0x73/0x1a0 > [ 613.398022] commit_tail+0x3d/0x70 [drm_kms_helper] > [ 613.398028] process_one_work+0x27d/0x600 > [ 613.398039] worker_thread+0x3c/0x390 > [ 613.398045] ? drain_workqueue+0x180/0x180 > [ 613.398049] kthread+0x120/0x140 > [ 613.398054] ? kthread_park+0x80/0x80 > [ 613.398060] ret_from_fork+0x27/0x50 > [ 613.398204] gdbus D13416 2138 1 0x8006 > [ 613.398211] Call Trace: > [ 613.398219] ? __schedule+0x2f3/0xb90 > [ 613.398224] ? sched_clock+0x5/0x10 > [ 613.398283] ? amdgpu_ctx_mgr_entity_flush+0x3c/0xc0 [amdgpu] > [ 613.398288] schedule+0x2f/0x90 > [ 613.398292] schedule_preempt_disabled+0x11/0x20 > [ 613.398296] __mutex_lock+0x25b/0x9c0 > [ 613.398360] ? amdgpu_ctx_mgr_entity_flush+0x3c/0xc0 [amdgpu] > [ 613.398415] amdgpu_ctx_mgr_entity_flush+0x3c/0xc0 [amdgpu] > [ 613.398468] amdgpu_flush+0x1f/0x30 [amdgpu] > [ 613.398474] filp_close+0x34/0x70 > [ 613.398481] put_files_struct.part.13+0x5b/0xc0 > [ 613.398489] do_exit+0x3df/0xca0 > [ 613.398495] ? sched_clock+0x5/0x10 > [ 613.398500] ? sched_clock_cpu+0xc/0xb0 > [ 613.398507] do_group_exit+0x47/0xc0 > [ 613.398513] get_signal+0x28f/0x850 > [ 613.398521] do_signal+0x36/0x650 > [ 613.398535] exit_to_usermode_loop+0x7b/0xe0 > [ 613.398540] do_syscall_64+0x1df/0x1f0 > [ 613.398546] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 613.398551] RIP: 0033:0x7f07a2e551f1 > [ 613.398558] Code: Bad RIP value. > [ 613.398562] RSP: 002b:7f079eb25860 EFLAGS: 0293 ORIG_RAX: > 0007 > [ 613.398566] RAX: 0003 RBX: 7f077c0689c0 RCX: > 7f07a2e551f1 > [ 613.398569] RDX: RSI: 0004 RDI: > 7f077c0689c0 > [ 613.398573] RBP: 0004 R08: R09: > 7f0784031d70 > [ 613.398576] R10: 55a328098420 R11: 0293 R12: > > [ 613.398579] R13: 7f07a3bb60f0 R14: R15: > 0004 > [ 613.399425] (sd-sync) D13944 6221 1 0x > [ 613.399432] Call Trace: > [ 613.399440] ? __schedule+0x2f3/0xb90 > [ 613.399446] ? prepare_to_wait_event+0xd2/0x180 > [ 613.399453] schedule+0x2f/0x90 > [ 613.399459] drm_sched_entity_flush+0x1df/0x1f0 [gpu_sched] > [ 613.399464] ? finish_wait+0x80/0x80 > [ 613.399521] amdgpu_ctx_mgr_entity_flush+0x7c/0xc0 [amdgpu] > [ 613.399574] amdgpu_flush+0x1f/0x30 [amdgpu] > [ 613.399580] filp_close+0x34/0x70 > [ 613.399585] __x64_sys_close+0x1e/0x50 > [ 613.399589] do_syscall_64+0x60/0x1f0 > [ 613.399594] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 613.399598] RIP: 0033:0x7f8d537d3ec7 > [ 613.399603] Code: Bad RIP value. > [ 613.399606] RSP: 002b:7ffc9df8e580 EFLAGS: 0293 ORIG_RAX: > 0003 > [ 613.399610] RAX: ffda RBX: 007b RCX: > 7f8d537d3ec7 > [ 613.399614] RDX: RSI: RDI: > 007b > [ 613.399617] RBP: 555bc87c5780 R08: 555bc87c628e R09: > > [ 613.399620] R10: 7f8d5376cae0 R11: 0293 R12: > 7f8d52aea750 > [ 613.399623] R13: R14: R15: > > [ 613.399636] (-restore)
Re: [PATCH i-g-t] igt: add timeline test cases v2
On 2018-12-11 5:37 a.m., Chunming Zhou wrote:
> v2: adapt to new transfer ioctl
>
> Signed-off-by: Chunming Zhou
+igt-dev
I think intel-gfx still works for IGT development but most of the IGT work
happens on igt-...@lists.freedesktop.org now.
Harry
> ---
> include/drm-uapi/drm.h | 33 ++
> lib/igt_syncobj.c| 206
> lib/igt_syncobj.h| 19 +
> tests/meson.build|1 +
> tests/syncobj_timeline.c | 1032 ++
> 5 files changed, 1291 insertions(+)
> create mode 100644 tests/syncobj_timeline.c
>
> diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
> index 85c685a2..dcd245d9 100644
> --- a/include/drm-uapi/drm.h
> +++ b/include/drm-uapi/drm.h
> @@ -731,6 +731,8 @@ struct drm_syncobj_handle {
>
> #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
> #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
> +/* wait for time point to become available */
> +#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2)
> struct drm_syncobj_wait {
> __u64 handles;
> /* absolute timeout */
> @@ -741,11 +743,38 @@ struct drm_syncobj_wait {
> __u32 pad;
> };
>
> +struct drm_syncobj_timeline_wait {
> +__u64 handles;
> +/* wait on specific timeline point for every handles*/
> +__u64 points;
> +/* absolute timeout */
> +__s64 timeout_nsec;
> +__u32 count_handles;
> +__u32 flags;
> +__u32 first_signaled; /* only valid when not waiting all */
> +__u32 pad;
> +};
> +
> struct drm_syncobj_array {
> __u64 handles;
> __u32 count_handles;
> __u32 pad;
> };
> +struct drm_syncobj_timeline_array {
> + __u64 handles;
> + __u64 points;
> + __u32 count_handles;
> + __u32 pad;
> +};
> +
> +struct drm_syncobj_transfer {
> +__u32 src_handle;
> +__u32 dst_handle;
> +__u64 src_point;
> +__u64 dst_point;
> +__u32 flags;
> +__u32 pad;
> +};
>
> /* Query current scanout sequence number */
> struct drm_crtc_get_sequence {
> @@ -902,6 +931,10 @@ extern "C" {
> #define DRM_IOCTL_MODE_LIST_LESSEES DRM_IOWR(0xC7, struct
> drm_mode_list_lessees)
> #define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
> drm_mode_get_lease)
> #define DRM_IOCTL_MODE_REVOKE_LEASE DRM_IOWR(0xC9, struct
> drm_mode_revoke_lease)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct
> drm_syncobj_timeline_wait)
> +#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct
> drm_syncobj_timeline_array)
> +#define DRM_IOCTL_SYNCOBJ_TRANSFERDRM_IOWR(0xCC, struct
> drm_syncobj_transfer)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct
> drm_syncobj_timeline_array)
>
> /**
> * Device specific ioctls should only be in their respective headers
> diff --git a/lib/igt_syncobj.c b/lib/igt_syncobj.c
> index d9114ca8..efa2adc4 100644
> --- a/lib/igt_syncobj.c
> +++ b/lib/igt_syncobj.c
> @@ -286,3 +286,209 @@ syncobj_signal(int fd, uint32_t *handles, uint32_t
> count)
> {
> igt_assert_eq(__syncobj_signal(fd, handles, count), 0);
> }
> +
> +static int
> +__syncobj_timeline_signal(int fd, uint32_t *handles, uint64_t *points,
> uint32_t count)
> +{
> + struct drm_syncobj_timeline_array array = { 0 };
> + int err = 0;
> +
> + array.handles = to_user_pointer(handles);
> + array.points = to_user_pointer(points);
> + array.count_handles = count;
> + if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, ))
> + err = -errno;
> + return err;
> +}
> +
> +/**
> + * syncobj_signal:
> + * @fd: The DRM file descriptor.
> + * @handles: Array of syncobj handles to signal
> + * @points: List of point of handles to signal.
> + * @count: Count of syncobj handles.
> + *
> + * Signal a set of syncobjs.
> + */
> +void
> +syncobj_timeline_signal(int fd, uint32_t *handles, uint64_t *points,
> uint32_t count)
> +{
> + igt_assert_eq(__syncobj_timeline_signal(fd, handles, points, count), 0);
> +}
> +int
> +__syncobj_timeline_wait_ioctl(int fd, struct drm_syncobj_timeline_wait *args)
> +{
> + int err = 0;
> + if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, args))
> + err = -errno;
> + return err;
> +}
> +static int
> +__syncobj_timeline_wait(int fd, uint32_t *handles, uint64_t *points,
> + unsigned num_handles,
> + int64_t timeout_nsec, unsigned flags,
> + uint32_t *first_signaled)
> +{
> + struct drm_syncobj_timeline_wait args;
> + int ret;
> +
> + args.handles = to_user_pointer(handles);
> + args.points = (uint64_t)to_user_pointer(points);
> + args.timeout_nsec = timeout_nsec;
> + args.count_handles = num_handles;
> + args.flags = flags;
> + args.first_signaled = 0;
> + args.pad = 0;
> +
> + ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, );
> + if (ret < 0)
> + return -errno;
> +
>
Re: [PATCH 04/16 v2] drm/amd/display: Add tracing to dc
On 2018-12-07 9:41 a.m., Wentland, Harry wrote: > On 2018-12-07 12:40 a.m., Kuehling, Felix wrote: >> This change seems to be breaking the build for me. I'm getting errors like >> this: >> >> CC [M] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o >> In file included from ../include/trace/events/tlb.h:9:0, >>from ../arch/x86/include/asm/mmu_context.h:10, >>from ../include/linux/mmu_context.h:5, >>from ../drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:30, >>from ../drivers/gpu/drm/amd/amdgpu/amdgpu.h:85, >>from >> ../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34: >> ../include/linux/tracepoint.h:285:20: error: redefinition of >> â__tpstrtab_amdgpu_dc_rregâ >> static const char __tpstrtab_##name[] \ >> ^ >> ../include/linux/tracepoint.h:293:2: note: in expansion of macro >> âDEFINE_TRACE_FNâ >> DEFINE_TRACE_FN(name, NULL, NULL); >> ^ >> ../include/trace/define_trace.h:28:2: note: in expansion of macro >> âDEFINE_TRACEâ >> DEFINE_TRACE(name) >> ^ >> ../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/./amdgpu_dm_trace.h:34:1: >> note: in expansion of macro âTRACE_EVENTâ >>TRACE_EVENT(amdgpu_dc_rreg, >>^ >> >> I have a local change that adds #include to amdgpu.h, >> which pulls in include/trace/events/tlb.h. That seems to create some kind of >> conflict with trace definitions. Any ideas how to fix this? It seems a bit >> fragile if adding some random include can break the build like this. >> > > That's the trace subsystem for you. David and I are trying to understand > what's going on. I think the problem is that both tlb.h and amdgpu_dm_trace.h > define trace events and we now include both here. > > I think we'd want to include neither trace events from amdgpu.h to avoid this > problem in the future, so we'll probably have to (a) clean up the dc.h > include to only contain what amdgpu.h needs and (b) clean up amdgpu_amdkfd.h > to only contain what amdgpu.h needs. At the end amdgpu.h doesn't care about > the tracer. The problem seems that dc.h and amdgpu_amdkfd.h are the main > includes for our respective drivers but are also wholesale included in > amdgpu.h. > Apologies for the spam. Just noticed that amdgpu.h includes only amdgpu_dm.h which is clean. The problem is that including amdgpu.h from amdgpu_dm.c now pulls in your trace events (from tlb.h) which we don't expect and care about. I think we should make sure amdgpu.h won't include anything that defines TRACE_EVENTs. Harry > Harry > >> Thanks, >> Felix >> >> -Original Message- >> From: amd-gfx On Behalf Of David >> Francis >> Sent: Friday, November 30, 2018 9:57 AM >> To: amd-gfx@lists.freedesktop.org >> Cc: Francis, David >> Subject: [PATCH 04/16 v2] drm/amd/display: Add tracing to dc >> >> [Why] >> Tracing is a useful and cheap debug functionality >> >> [How] >> This creates a new trace system amdgpu_dm, currently with three trace events >> >> amdgpu_dc_rreg and amdgpu_dc_wreg report the address and value of any dc >> register reads and writes >> >> amdgpu_dc_performance requires at least one of those two to be enabled. It >> counts the register reads and writes since the last entry >> >> v2: Don't check for NULL before kfree >> >> Signed-off-by: David Francis >> Reviewed-by: Harry Wentland >> Acked-by: Leo Li >> --- >>.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 + >>.../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 104 ++ >>drivers/gpu/drm/amd/display/dc/core/dc.c | 19 >>drivers/gpu/drm/amd/display/dc/dc_types.h | 8 ++ >>.../amd/display/dc/dcn10/dcn10_cm_common.c| 4 +- >>drivers/gpu/drm/amd/display/dc/dm_services.h | 12 +- >>6 files changed, 146 insertions(+), 4 deletions(-) create mode 100644 >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h >> >> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >> index 76b1aebdca0c..376927c8bcc6 100644 >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >> @@ -23,6 +23,9 @@ >> * >> */ >> >> +/* The caprices of the preprocessor require that this be declared right >> +here */ #define CREATE_TRACE_POINTS >> + >&g
Re: [PATCH 04/16 v2] drm/amd/display: Add tracing to dc
On 2018-12-07 12:40 a.m., Kuehling, Felix wrote: > This change seems to be breaking the build for me. I'm getting errors like > this: > >CC [M] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o > In file included from ../include/trace/events/tlb.h:9:0, > from ../arch/x86/include/asm/mmu_context.h:10, > from ../include/linux/mmu_context.h:5, > from ../drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:30, > from ../drivers/gpu/drm/amd/amdgpu/amdgpu.h:85, > from > ../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:34: > ../include/linux/tracepoint.h:285:20: error: redefinition of > â__tpstrtab_amdgpu_dc_rregâ >static const char __tpstrtab_##name[] \ > ^ > ../include/linux/tracepoint.h:293:2: note: in expansion of macro > âDEFINE_TRACE_FNâ >DEFINE_TRACE_FN(name, NULL, NULL); >^ > ../include/trace/define_trace.h:28:2: note: in expansion of macro > âDEFINE_TRACEâ >DEFINE_TRACE(name) >^ > ../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/./amdgpu_dm_trace.h:34:1: > note: in expansion of macro âTRACE_EVENTâ > TRACE_EVENT(amdgpu_dc_rreg, > ^ > > I have a local change that adds #include to amdgpu.h, which > pulls in include/trace/events/tlb.h. That seems to create some kind of > conflict with trace definitions. Any ideas how to fix this? It seems a bit > fragile if adding some random include can break the build like this. > That's the trace subsystem for you. David and I are trying to understand what's going on. I think the problem is that both tlb.h and amdgpu_dm_trace.h define trace events and we now include both here. I think we'd want to include neither trace events from amdgpu.h to avoid this problem in the future, so we'll probably have to (a) clean up the dc.h include to only contain what amdgpu.h needs and (b) clean up amdgpu_amdkfd.h to only contain what amdgpu.h needs. At the end amdgpu.h doesn't care about the tracer. The problem seems that dc.h and amdgpu_amdkfd.h are the main includes for our respective drivers but are also wholesale included in amdgpu.h. Harry > Thanks, >Felix > > -Original Message- > From: amd-gfx On Behalf Of David > Francis > Sent: Friday, November 30, 2018 9:57 AM > To: amd-gfx@lists.freedesktop.org > Cc: Francis, David > Subject: [PATCH 04/16 v2] drm/amd/display: Add tracing to dc > > [Why] > Tracing is a useful and cheap debug functionality > > [How] > This creates a new trace system amdgpu_dm, currently with three trace events > > amdgpu_dc_rreg and amdgpu_dc_wreg report the address and value of any dc > register reads and writes > > amdgpu_dc_performance requires at least one of those two to be enabled. It > counts the register reads and writes since the last entry > > v2: Don't check for NULL before kfree > > Signed-off-by: David Francis > Reviewed-by: Harry Wentland > Acked-by: Leo Li > --- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 + > .../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 104 ++ > drivers/gpu/drm/amd/display/dc/core/dc.c | 19 > drivers/gpu/drm/amd/display/dc/dc_types.h | 8 ++ > .../amd/display/dc/dcn10/dcn10_cm_common.c| 4 +- > drivers/gpu/drm/amd/display/dc/dm_services.h | 12 +- > 6 files changed, 146 insertions(+), 4 deletions(-) create mode 100644 > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 76b1aebdca0c..376927c8bcc6 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -23,6 +23,9 @@ >* >*/ > > +/* The caprices of the preprocessor require that this be declared right > +here */ #define CREATE_TRACE_POINTS > + > #include "dm_services_types.h" > #include "dc.h" > #include "dc/inc/core_types.h" > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h > new file mode 100644 > index ..d898981684d5 > --- /dev/null > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h > @@ -0,0 +1,104 @@ > +/* > + * Copyright 2018 Advanced Micro Devices, Inc. > + * > + * Permission is hereby granted, free of charge, to any person > +obtaining a > + * copy of this software and associated documentation files (the > +"Software"), > + * to deal in the Software without restriction, including without > +limitation > + * the rights to use, copy, modify, merge, publish, distribute, > +sublicense, > + * and/or sell copies of the Software, and to permit persons to whom > +the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be > +included in > + * all copies or substantial portions of the
Re: [PATCH] drm/amd/display: Fix NULL ptr deref for commit_planes_to_stream
On 2018-11-30 10:09 a.m., Nicholas Kazlauskas wrote:
> [Why]
> With scaling, underscan and abm changes we can end up calling
> commit_planes_to_stream in commit_tail. This call uses dm_state->context
> which can be NULL if the commit was a fast update.
>
> [How]
> Use dc_state instead since that can't be NULL unless the system ran
> out of memory.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108912
> Fixes: e64abff2f133 ("drm/amd/display: Use private obj helpers for
> dm_atomic_state")
>
> Cc: Leo Li
> Cc: Harry Wentland
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 76b1aebdca0c..8ecd78657d43 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5011,7 +5011,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
> drm_atomic_state *state)
> status->plane_count,
> dm_new_crtc_state,
> to_dm_crtc_state(old_crtc_state),
> - dm_state->context))
> + dc_state))
> dm_error("%s: Failed to update stream scaling!\n",
> __func__);
> }
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: amdgpu driver, Screen artifacts on >=75 Hz FHD display unless forced power state, if there was >=75 Hz when Xorg started.
Does this patch help you? https://patchwork.freedesktop.org/patch/264781/ The easiest way to test it would be to build and try the amd-staging-drm-next branch from https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next Which monitors are you using and how are they connected (DP, HDMI, any adapters)? Harry On 2018-11-22 11:34 a.m., Piotr Karbowski wrote: > Hi, > > I am facing a common issue with a screen artifacts whenever I start my Xorg > on AMDGPU driver with display set to 75 Hz 1920x1080. It appears to be > hitting all the users of AMDGPU driver. > > https://bugs.freedesktop.org/show_bug.cgi?id=96868 > https://bugs.freedesktop.org/show_bug.cgi?id=102646 > > Here I am running the Polaris, RX 580 8G variant. > > I've noticed that if I disable freesync *before* starting Xorg, which makes > my Xorg starts with default 60Hz, I have no screen artifacts. If however I > start Xorg with freesync on (in monitor), XOrg defaults to 75 Hz and I have > random screen tearing and artifacts. What is worth a note is that if I enable > freesync and/or change from 60 Hz to 75 Hz after Xorg started, I have no > screen artifacts. Same goes if I switch to 60 Hz via xrandr and/or disable > freesync in Monitor OSD during Xorg run time, the screen artifacts still > happen. > > Forcing power state to lowest with > > echo low >/sys/class/drm/card0/device/power_dpm_force_performance_level > > Does make the screen artifacts go away, during runtime, without restart. > > I found it a bit surprising that it appears it's about the state of > monitor/default frequency of the moment when Xorg was started rather than > the the currently running frequency of the screen. As with low mode, I Have > 300 MHz on mclk and sclk and no screen artifacts it may mean that it's not > about not enough power on the GPU to handle it, rather than something that > happens when the power states switches. > > Some additional information: > > - I am running simple openbox WM > - Vanilla 4.19.2 kernel > - x11-drivers/xf86-video-amdgpu-18.1.0 > - x11-base/xorg-server-1.20.3 > > Would you kindly share your thoughts about above problem? > > -- Piotr. > > > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: limit high pixel clock modes on ST/CZ
Hersen confirmed 4k60 works fine over DP. The problem here are really just USB-C ports and associated dongles. We've never supported USB-C dongles on CZ/ST before. Harry On 2018-11-27 1:49 p.m., S, Shirish wrote: > This is for the devices with type-c ports. > > Wherein the signal type is same 32 (DISPLAY PORT) for both HDMI and DP > monitors connected to the system via type-c dongles/convertors. > > Regards, > Shirish S > > Get Outlook for Android <https://aka.ms/ghei36> > > -- > *From:* Deucher, Alexander > *Sent:* Wednesday, November 28, 2018 12:06:26 AM > *To:* S, Shirish; Li, Sun peng (Leo); Wentland, Harry > *Cc:* amd-gfx@lists.freedesktop.org > *Subject:* Re: [PATCH] drm/amd/display: limit high pixel clock modes on ST/CZ > > > Is this a DP to HDMI adapter? I think 4k@60 should be valid on DP in general > on ST/CZ, but Harry or Leo should comment. > > > Alex > > -- > *From:* S, Shirish > *Sent:* Tuesday, November 27, 2018 3:58:12 AM > *To:* Deucher, Alexander; Li, Sun peng (Leo); Wentland, Harry > *Cc:* amd-gfx@lists.freedesktop.org > *Subject:* RE: [PATCH] drm/amd/display: limit high pixel clock modes on ST/CZ > > > However, while using Type-C connectors noted that the signal type is actually > SIGNAL_TYPE_DISPLAY_PORT and found that the check was missing. > > Hence have added the same in https://patchwork.freedesktop.org/patch/264033/ > > > > Regards, > > Shirish S > > > > *From:* S, Shirish > *Sent:* Tuesday, November 27, 2018 9:54 AM > *To:* Deucher, Alexander ; Li, Sun peng (Leo) > ; Wentland, Harry > *Cc:* amd-gfx@lists.freedesktop.org > *Subject:* RE: [PATCH] drm/amd/display: limit high pixel clock modes on ST/CZ > > > > Thanks Alex, found that patch. > > My patch is no more required. > > > > > > Regards, > > Shirish S > > > > *From:* Deucher, Alexander <mailto:alexander.deuc...@amd.com>> > *Sent:* Monday, November 26, 2018 7:46 PM > *To:* S, Shirish mailto:shiris...@amd.com>>; Li, Sun peng > (Leo) mailto:sunpeng...@amd.com>>; Wentland, Harry > mailto:harry.wentl...@amd.com>> > *Cc:* amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org> > *Subject:* Re: [PATCH] dr
Re: [PATCH] drm/amd/display: Fix unintialized max_bpc state values
On 2018-11-29 10:44 a.m., Nicholas Kazlauskas wrote:
> [Why]
> If the "max bpc" isn't explicitly set in the atomic state then it
> have a value of 0. This has the correct behavior of limiting a panel
> to 8bpc in the case where the panel supports 8bpc. In the case of eDP
> panels this isn't a true assumption - there are panels that can only
> do 6bpc.
>
> Banding occurs for these displays.
>
> [How]
> Initialize the max_bpc when the connector resets to 8bpc. Also carry
> over the value when the state is duplicated.
>
> Bugzilla: https://bugs.freedesktop.org/108825
> Fixes: 307638884f72 ("drm/amd/display: Support amdgpu "max bpc" connector
> property")
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index ce00e56814ed..ede93d53e209 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3215,6 +3215,7 @@ void amdgpu_dm_connector_funcs_reset(struct
> drm_connector *connector)
> state->underscan_enable = false;
> state->underscan_hborder = 0;
> state->underscan_vborder = 0;
> + state->max_bpc = 8;
>
> __drm_atomic_helper_connector_reset(connector, >base);
> }
> @@ -3236,6 +3237,7 @@ amdgpu_dm_connector_atomic_duplicate_state(struct
> drm_connector *connector)
>
> new_state->freesync_capable = state->freesync_capable;
> new_state->abm_level = state->abm_level;
> + new_state->max_bpc = state->max_bpc;
>
> return _state->base;
> }
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Disable 4k@60 on DP as well for DCE11
On 2018-11-27 3:52 a.m., S, Shirish wrote:
> This patch extends the below patch to apply DP signal type, for exactly
> the same reasons it was disabled for HDMI.
>
> "1a0e348 drm/amd/display: Disable 4k 60 HDMI on DCE11"
>
> Signed-off-by: Shirish S
> ---
> drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
> index 3e18ea8..d578828 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
> @@ -662,6 +662,10 @@ bool dce110_link_encoder_validate_dp_output(
> const struct dce110_link_encoder *enc110,
> const struct dc_crtc_timing *crtc_timing)
> {
> + if (crtc_timing->pix_clk_khz >
> + enc110->base.features.max_hdmi_pixel_clock)
> + return false;
> +
It doesn't make sense to look at the max hdmi pixel for DP.
If we want to restrict the supported timings we should also make sure they only
apply to Stoney and/or Carrizo. That said, are you sure 4k60 is an issue on all
CZ/ST boards or is this particular to a certain platform?
Harry
> if (crtc_timing->pixel_encoding == PIXEL_ENCODING_YCBCR420)
> return false;
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Fix compile error with ACPI disabled
On 2018-11-27 11:18 a.m., David Francis wrote: > The fallback code for getting default backlight caps was using > the wrong variable name. Fix it. > > Fixes: > https://lists.freedesktop.org/archives/dri-devel/2018-November/197752.html > Signed-off-by: David Francis Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 27df3ae945be..aa3f8200fa69 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -1615,8 +1615,8 @@ static void amdgpu_dm_update_backlight_caps(struct > amdgpu_display_manager *dm) > AMDGPU_DM_DEFAULT_MAX_BACKLIGHT; > } > #else > - dm->backlight_min_input_signal = AMDGPU_DM_DEFAULT_MIN_BACKLIGHT; > - dm->backlight_max_input_signal = AMDGPU_DM_DEFAULT_MAX_BACKLIGHT; > + dm->backlight_caps.min_input_signal = AMDGPU_DM_DEFAULT_MIN_BACKLIGHT; > + dm->backlight_caps.max_input_signal = AMDGPU_DM_DEFAULT_MAX_BACKLIGHT; > #endif > } > > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v7 3/5] drm: Document variable refresh properties
On 2018-11-27 4:22 a.m., Daniel Vetter wrote: > On Mon, Nov 12, 2018 at 04:12:10PM +0000, Wentland, Harry wrote: >> On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote: >>> These include the drm_connector 'vrr_capable' and the drm_crtc >>> 'vrr_enabled' properties. >>> >>> Signed-off-by: Nicholas Kazlauskas >>> Cc: Harry Wentland >>> Cc: Manasi Navare >>> Cc: Pekka Paalanen >>> Cc: Ville Syrjälä >>> Cc: Michel Dänzer >> >> Looks good. Whole series is >> Reviewed-by: Harry Wentland >> >> How are we with the userspace patches? We should probably hold off >> pushing the kernel patches until the userspace work is all reviewed. > > Do some igts exist for this too? Especially for tricky pieces of uapi > having a non-vendor reference code somewhere would be good, aside from > testing and all that. Not yet, unfortunately, although it's on our list of things to do. Harry > -Daniel > >> >> Harry >> >>> --- >>> Documentation/gpu/drm-kms.rst | 7 >>> drivers/gpu/drm/drm_connector.c | 68 + >>> 2 files changed, 75 insertions(+) >>> >>> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst >>> index 4b1501b4835b..8da2a178cf85 100644 >>> --- a/Documentation/gpu/drm-kms.rst >>> +++ b/Documentation/gpu/drm-kms.rst >>> @@ -575,6 +575,13 @@ Explicit Fencing Properties >>> .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c >>> :doc: explicit fencing properties >>> >>> + >>> +Variable Refresh Properties >>> +--- >>> + >>> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c >>> + :doc: Variable refresh properties >>> + >>> Existing KMS Properties >>> --- >>> >>> diff --git a/drivers/gpu/drm/drm_connector.c >>> b/drivers/gpu/drm/drm_connector.c >>> index 49290060ab7b..0e4287461997 100644 >>> --- a/drivers/gpu/drm/drm_connector.c >>> +++ b/drivers/gpu/drm/drm_connector.c >>> @@ -1255,6 +1255,74 @@ int drm_mode_create_scaling_mode_property(struct >>> drm_device *dev) >>> } >>> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property); >>> >>> +/** >>> + * DOC: Variable refresh properties >>> + * >>> + * Variable refresh rate capable displays can dynamically adjust their >>> + * refresh rate by extending the duration of their vertical front porch >>> + * until page flip or timeout occurs. This can reduce or remove stuttering >>> + * and latency in scenarios where the page flip does not align with the >>> + * vblank interval. >>> + * >>> + * An example scenario would be an application flipping at a constant rate >>> + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank >>> + * interval and the same contents will be displayed twice. This can be >>> + * observed as stuttering for content with motion. >>> + * >>> + * If variable refresh rate was active on a display that supported a >>> + * variable refresh range from 35Hz to 60Hz no stuttering would be >>> observable >>> + * for the example scenario. The minimum supported variable refresh rate of >>> + * 35Hz is below the page flip frequency and the vertical front porch can >>> + * be extended until the page flip occurs. The vblank interval will be >>> + * directly aligned to the page flip rate. >>> + * >>> + * Not all userspace content is suitable for use with variable refresh >>> rate. >>> + * Large and frequent changes in vertical front porch duration may worsen >>> + * perceived stuttering for input sensitive applications. >>> + * >>> + * Panel brightness will also vary with vertical front porch duration. Some >>> + * panels may have noticeable differences in brightness between the minimum >>> + * vertical front porch duration and the maximum vertical front porch >>> duration. >>> + * Large and frequent changes in vertical front porch duration may produce >>> + * observable flickering for such panels. >>> + * >>> + * Userspace control for variable refresh rate is supported via properties >>> + * on the _connector and _crtc objects. >>> + * >>> + * "vrr_capable": >>> + * Optional _connector boolean property that drivers should attach >>> + * with drm_connector_attach_vrr_capable_property() on connectors that >&g
Re: [PATCH v7 3/5] drm: Document variable refresh properties
On 2018-11-12 12:05 p.m., Kazlauskas, Nicholas wrote: > On 11/12/18 11:12 AM, Wentland, Harry wrote: >> On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote: >>> These include the drm_connector 'vrr_capable' and the drm_crtc >>> 'vrr_enabled' properties. >>> >>> Signed-off-by: Nicholas Kazlauskas >>> Cc: Harry Wentland >>> Cc: Manasi Navare >>> Cc: Pekka Paalanen >>> Cc: Ville Syrjälä >>> Cc: Michel Dänzer >> >> Looks good. Whole series is >> Reviewed-by: Harry Wentland >> >> How are we with the userspace patches? We should probably hold off pushing >> the kernel patches until the userspace work is all reviewed. >> >> Harry > > Thanks for the review. > > The xf86-video-amdgpu patches have been reviewed and the mesa patches > have been partially reviewed. > Alex, Michel, how do we merge changes like this that provide a kernel API that goes together with userspace changes? I imagine we'd want to get the kernel changes in first, and then merge the xf86-video-amdgpu and mesa changes. Please correct me if I'm wrong. Any objections to getting this merged via the usual amd-stg? Thanks, Harry > Nicholas Kazlauskas > >> >>> --- >>> Documentation/gpu/drm-kms.rst | 7 >>> drivers/gpu/drm/drm_connector.c | 68 + >>> 2 files changed, 75 insertions(+) >>> >>> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst >>> index 4b1501b4835b..8da2a178cf85 100644 >>> --- a/Documentation/gpu/drm-kms.rst >>> +++ b/Documentation/gpu/drm-kms.rst >>> @@ -575,6 +575,13 @@ Explicit Fencing Properties >>> .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c >>> :doc: explicit fencing properties >>> >>> + >>> +Variable Refresh Properties >>> +--- >>> + >>> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c >>> + :doc: Variable refresh properties >>> + >>> Existing KMS Properties >>> --- >>> >>> diff --git a/drivers/gpu/drm/drm_connector.c >>> b/drivers/gpu/drm/drm_connector.c >>> index 49290060ab7b..0e4287461997 100644 >>> --- a/drivers/gpu/drm/drm_connector.c >>> +++ b/drivers/gpu/drm/drm_connector.c >>> @@ -1255,6 +1255,74 @@ int drm_mode_create_scaling_mode_property(struct >>> drm_device *dev) >>> } >>> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property); >>> >>> +/** >>> + * DOC: Variable refresh properties >>> + * >>> + * Variable refresh rate capable displays can dynamically adjust their >>> + * refresh rate by extending the duration of their vertical front porch >>> + * until page flip or timeout occurs. This can reduce or remove stuttering >>> + * and latency in scenarios where the page flip does not align with the >>> + * vblank interval. >>> + * >>> + * An example scenario would be an application flipping at a constant rate >>> + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank >>> + * interval and the same contents will be displayed twice. This can be >>> + * observed as stuttering for content with motion. >>> + * >>> + * If variable refresh rate was active on a display that supported a >>> + * variable refresh range from 35Hz to 60Hz no stuttering would be >>> observable >>> + * for the example scenario. The minimum supported variable refresh rate of >>> + * 35Hz is below the page flip frequency and the vertical front porch can >>> + * be extended until the page flip occurs. The vblank interval will be >>> + * directly aligned to the page flip rate. >>> + * >>> + * Not all userspace content is suitable for use with variable refresh >>> rate. >>> + * Large and frequent changes in vertical front porch duration may worsen >>> + * perceived stuttering for input sensitive applications. >>> + * >>> + * Panel brightness will also vary with vertical front porch duration. Some >>> + * panels may have noticeable differences in brightness between the minimum >>> + * vertical front porch duration and the maximum vertical front porch >>> duration. >>> + * Large and frequent changes in vertical front porch duration may produce >>> + * observable flickering for such panels. >>> + * >>> + * Userspace control for variable refresh rate is supported via properties >>> + * on the _connec
Re: [PATCH] drm/amd: Query and use ACPI backlight caps
On 2018-11-20 10:16 a.m., David Francis wrote:
> ACPI ATIF has a function called query
> backlight transfer characteristics. Among the
> information returned by this function is
> the minimum and maximum input signals for the
> backlight
>
> Call that function on ACPI init. When DM
> backlight device is updated, copy over the
> backlight caps into DM, but only once. Use
> the backlight caps in the backlight-to-dc
> calculation.
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 83 +++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 59 ++---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 13 +++
> drivers/gpu/drm/amd/include/amd_acpi.h| 24 ++
> 5 files changed, 170 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 2c80453ca350..adbad0e2d4ea 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1255,6 +1255,9 @@ bool
> amdgpu_acpi_is_pcie_performance_request_supported(struct amdgpu_device *ade
> int amdgpu_acpi_pcie_performance_request(struct amdgpu_device *adev,
> u8 perf_req, bool advertise);
> int amdgpu_acpi_pcie_notify_device_ready(struct amdgpu_device *adev);
> +
> +void amdgpu_acpi_get_backlight_caps(struct amdgpu_device *adev,
> + struct amdgpu_dm_backlight_caps *caps);
> #else
> static inline int amdgpu_acpi_init(struct amdgpu_device *adev) { return 0; }
> static inline void amdgpu_acpi_fini(struct amdgpu_device *adev) { }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> index 471266901d1b..47db65926d71 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> @@ -65,6 +65,7 @@ struct amdgpu_atif {
> struct amdgpu_atif_functions functions;
> struct amdgpu_atif_notification_cfg notification_cfg;
> struct amdgpu_encoder *encoder_for_bl;
> + struct amdgpu_dm_backlight_caps backlight_caps;
> };
>
> /* Call the ATIF method
> @@ -297,6 +298,65 @@ static int amdgpu_atif_get_notification_params(struct
> amdgpu_atif *atif)
> return err;
> }
>
> +/**
> + * amdgpu_atif_query_backlight_caps - get min and max backlight input signal
> + *
> + * @handle: acpi handle
> + *
> + * Execute the QUERY_BRIGHTNESS_TRANSFER_CHARACTERISTICS ATIF function
> + * to determine the acceptable range of backlight values
> + *
> + * Backlight_caps.caps_valid will be set to true if the query is successful
> + *
> + * The input signals are in range 0-255
> + *
> + * This function assumes the display with backlight is the first LCD
> + *
> + * Returns 0 on success, error on failure.
> + */
> +static int amdgpu_atif_query_backlight_caps(struct amdgpu_atif *atif)
> +{
> + union acpi_object *info;
> + struct atif_qbtc_output characteristics;
> + struct atif_qbtc_arguments arguments;
> + struct acpi_buffer params;
> + size_t size;
> + int err = 0;
> +
> + arguments.size = sizeof(arguments);
> + arguments.requested_display = ATIF_QBTC_REQUEST_LCD1;
> +
> + params.length = sizeof(arguments);
> + params.pointer = (void *)
> +
> + info = amdgpu_atif_call(atif,
> + ATIF_FUNCTION_QUERY_BRIGHTNESS_TRANSFER_CHARACTERISTICS,
> + );
> + if (!info) {
> + err = -EIO;
> + goto out;
> + }
> +
> + size = *(u16 *) info->buffer.pointer;
> + if (size < 10) {
> + err = -EINVAL;
> + goto out;
> + }
> +
> + memset(, 0, sizeof(characteristics));
> + size = min(sizeof(characteristics), size);
> + memcpy(, info->buffer.pointer, size);
> +
> + atif->backlight_caps.caps_valid = true;
> + atif->backlight_caps.min_input_signal =
> + characteristics.min_input_signal;
> + atif->backlight_caps.max_input_signal =
> + characteristics.max_input_signal;
> +out:
> + kfree(info);
> + return err;
> +}
> +
> /**
> * amdgpu_atif_get_sbios_requests - get requested sbios event
> *
> @@ -786,6 +846,17 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
> }
> }
>
> + if (atif->functions.query_backlight_transfer_characteristics) {
> + ret = amdgpu_atif_query_backlight_caps(atif);
> + if (ret) {
> + D
Re: [PATCH v4 2/2] drm/amd: Add abm level drm property
On 2018-11-20 11:00 a.m., David Francis wrote:
> Adaptive Backlight Management (ABM) is a feature
> that reduces backlight level to save power, while
> increasing pixel contrast and pixel luminance
> to maintain readability and image quality.
>
> ABM will adjust in response to the
> pixel luminance of the displayed content.
>
> ABM is made available as a drm property on eDP
> monitors called "abm level", which ranges from 0 to 4.
> When this property is set to 0, ABM is off. Levels 1
> to 4 represent different ranges of backlight reduction.
> At higher levels both the backlight reduction and pixel
> adjustment will be greater.
>
> ABM requires DMCU firmware, which is currently available for
> Raven ASICs only. If the feature does not work, please
> ensure your firmware is up to date.
>
> v2:
> Fix commit message, only attach property if DMCU loaded
> v3:
> Store ABM level in crtc state to accommodate dc
> v4:
> Fix ABM saving on dpms cycle
>
> Signed-off-by: David Francis
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 ++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 ++
> drivers/gpu/drm/amd/display/dc/core/dc.c | 11 +-
> drivers/gpu/drm/amd/display/dc/dc.h | 1 +
> 6 files changed, 53 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 7d6a36bca9dd..ced8cefa223b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -637,6 +637,11 @@ int amdgpu_display_modeset_create_props(struct
> amdgpu_device *adev)
>"freesync_capable");
> if (!adev->mode_info.freesync_capable_property)
> return -ENOMEM;
> + adev->mode_info.abm_level_property =
> + drm_property_create_range(adev->ddev, 0,
> + "abm level", 0, 4);
> + if (!adev->mode_info.abm_level_property)
> + return -ENOMEM;
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 1627dd3413c7..2938635c0fc1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -342,6 +342,8 @@ struct amdgpu_mode_info {
> struct drm_property *freesync_property;
> /* it is used to know about display capability of freesync mode */
> struct drm_property *freesync_capable_property;
> + /* Adaptive Backlight Modulation (power feature) */
> + struct drm_property *abm_level_property;
> /* hardcoded DFP edid from BIOS */
> struct edid *bios_hardcoded_edid;
> int bios_hardcoded_edid_size;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index f71febb4210d..95b1106e0662 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2920,6 +2920,7 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
> state->adjust = cur->adjust;
> state->vrr_infopacket = cur->vrr_infopacket;
> state->freesync_enabled = cur->freesync_enabled;
> + state->abm_level = cur->abm_level;
>
> /* TODO Duplicate dc_stream after objects are stream object is
> flattened */
>
> @@ -3038,6 +3039,9 @@ int amdgpu_dm_connector_atomic_set_property(struct
> drm_connector *connector,
> } else if (property == adev->mode_info.freesync_capable_property) {
> dm_new_state->freesync_capable = val;
> ret = 0;
> + } else if (property == adev->mode_info.abm_level_property) {
> + dm_new_state->abm_level = val;
> + ret = 0;
> }
>
> return ret;
> @@ -3086,7 +3090,11 @@ int amdgpu_dm_connector_atomic_get_property(struct
> drm_connector *connector,
> } else if (property == adev->mode_info.freesync_capable_property) {
> *val = dm_state->freesync_capable;
> ret = 0;
> + } else if (property == adev->mode_info.abm_level_property) {
> + *val = dm_state->abm_level;
> + ret = 0;
> }
> +
> return ret;
> }
>
> @@ -3151,6 +3159,7 @@ amdgpu_dm_connector_atomic_duplicate
Re: [PATCH] drm/amd/pp: Fix truncated clock value when set watermark
On 2018-11-12 10:32 p.m., Rex Zhu wrote:
> the clk value should be tranferred to MHz first and
> then transfer to uint16. otherwise, the clock value
> will be truncated.
>
> Reported-by: Hersen Wu
> Signed-off-by: Rex Zhu
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 32
>
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
> index 99a33c3..101c09b 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
> @@ -713,20 +713,20 @@ int smu_set_watermarks_for_clocks_ranges(void *wt_table,
> for (i = 0; i < wm_with_clock_ranges->num_wm_dmif_sets; i++) {
> table->WatermarkRow[1][i].MinClock =
> cpu_to_le16((uint16_t)
> -
> (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_dcfclk_clk_in_khz) /
> - 1000);
> +
> (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_dcfclk_clk_in_khz /
> + 1000));
> table->WatermarkRow[1][i].MaxClock =
> cpu_to_le16((uint16_t)
> -
> (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_dcfclk_clk_in_khz) /
> - 1000);
> +
> (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_dcfclk_clk_in_khz /
> + 1000));
> table->WatermarkRow[1][i].MinUclk =
> cpu_to_le16((uint16_t)
> -
> (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_mem_clk_in_khz) /
> - 1000);
> +
> (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_mem_clk_in_khz /
> + 1000));
> table->WatermarkRow[1][i].MaxUclk =
> cpu_to_le16((uint16_t)
> -
> (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_mem_clk_in_khz) /
> - 1000);
> +
> (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_mem_clk_in_khz /
> + 1000));
> table->WatermarkRow[1][i].WmSetting = (uint8_t)
>
> wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_set_id;
> }
> @@ -734,20 +734,20 @@ int smu_set_watermarks_for_clocks_ranges(void *wt_table,
> for (i = 0; i < wm_with_clock_ranges->num_wm_mcif_sets; i++) {
> table->WatermarkRow[0][i].MinClock =
> cpu_to_le16((uint16_t)
> -
> (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_min_socclk_clk_in_khz) /
> - 1000);
> +
> (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_min_socclk_clk_in_khz /
> + 1000));
> table->WatermarkRow[0][i].MaxClock =
> cpu_to_le16((uint16_t)
> -
> (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_max_socclk_clk_in_khz) /
> - 1000);
> +
> (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_max_socclk_clk_in_khz /
> + 1000));
> table->WatermarkRow[0][i].MinUclk =
> cpu_to_le16((uint16_t)
> -
> (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_min_mem_clk_in_khz) /
> - 1000);
> +
> (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_min_mem_clk_in_khz /
> + 1000));
> table->WatermarkRow[0][i].MaxUclk =
> cpu_to_le16((uint16_t)
> -
> (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_max_mem_clk_in_khz) /
> - 1000);
> +
> (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_max_mem_clk_in_khz /
> + 1000));
> table->WatermarkRow[0][i].WmSetting = (uint8_t)
>
> wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_set_id;
> }
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v7 3/5] drm: Document variable refresh properties
On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote: > These include the drm_connector 'vrr_capable' and the drm_crtc > 'vrr_enabled' properties. > > Signed-off-by: Nicholas Kazlauskas > Cc: Harry Wentland > Cc: Manasi Navare > Cc: Pekka Paalanen > Cc: Ville Syrjälä > Cc: Michel Dänzer Looks good. Whole series is Reviewed-by: Harry Wentland How are we with the userspace patches? We should probably hold off pushing the kernel patches until the userspace work is all reviewed. Harry > --- > Documentation/gpu/drm-kms.rst | 7 > drivers/gpu/drm/drm_connector.c | 68 + > 2 files changed, 75 insertions(+) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index 4b1501b4835b..8da2a178cf85 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -575,6 +575,13 @@ Explicit Fencing Properties > .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c > :doc: explicit fencing properties > > + > +Variable Refresh Properties > +--- > + > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c > + :doc: Variable refresh properties > + > Existing KMS Properties > --- > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index 49290060ab7b..0e4287461997 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1255,6 +1255,74 @@ int drm_mode_create_scaling_mode_property(struct > drm_device *dev) > } > EXPORT_SYMBOL(drm_mode_create_scaling_mode_property); > > +/** > + * DOC: Variable refresh properties > + * > + * Variable refresh rate capable displays can dynamically adjust their > + * refresh rate by extending the duration of their vertical front porch > + * until page flip or timeout occurs. This can reduce or remove stuttering > + * and latency in scenarios where the page flip does not align with the > + * vblank interval. > + * > + * An example scenario would be an application flipping at a constant rate > + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank > + * interval and the same contents will be displayed twice. This can be > + * observed as stuttering for content with motion. > + * > + * If variable refresh rate was active on a display that supported a > + * variable refresh range from 35Hz to 60Hz no stuttering would be observable > + * for the example scenario. The minimum supported variable refresh rate of > + * 35Hz is below the page flip frequency and the vertical front porch can > + * be extended until the page flip occurs. The vblank interval will be > + * directly aligned to the page flip rate. > + * > + * Not all userspace content is suitable for use with variable refresh rate. > + * Large and frequent changes in vertical front porch duration may worsen > + * perceived stuttering for input sensitive applications. > + * > + * Panel brightness will also vary with vertical front porch duration. Some > + * panels may have noticeable differences in brightness between the minimum > + * vertical front porch duration and the maximum vertical front porch > duration. > + * Large and frequent changes in vertical front porch duration may produce > + * observable flickering for such panels. > + * > + * Userspace control for variable refresh rate is supported via properties > + * on the _connector and _crtc objects. > + * > + * "vrr_capable": > + * Optional _connector boolean property that drivers should attach > + * with drm_connector_attach_vrr_capable_property() on connectors that > + * could support variable refresh rates. Drivers should update the > + * property value by calling drm_connector_set_vrr_capable_property(). > + * > + * Absence of the property should indicate absence of support. > + * > + * "vrr_enabled": > + * Default _crtc boolean property that notifies the driver that the > + * content on the CRTC is suitable for variable refresh rate presentation. > + * The driver will take this property as a hint to enable variable > + * refresh rate support if the receiver supports it, ie. if the > + * "vrr_capable" property is true on the _connector object. The > + * vertical front porch duration will be extended until page-flip or > + * timeout when enabled. > + * > + * The minimum vertical front porch duration is defined as the vertical > + * front porch duration for the current mode. > + * > + * The maximum vertical front porch duration is greater than or equal to > + * the minimum vertical front porch duration. The duration is derived > + * from the minimum supported variable refresh rate for the connector. > + * > + * The driver may place further restrictions within these minimum > + * and maximum bounds. > + * > + * The semantics for the vertical blank timestamp differ when > + * variable refresh rate is active. The vertical blank timestamp > + * is defined to be an estimate using the current mode's fixed > +
Re: [PATCH v2 2/2] drm/amd/display: Support amdgpu "max bpc" connector property
On 2018-11-07 12:50 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Many panels support more than 8bpc but some modes are unavailable while
> running at greater than 8bpc due to DP/HDMI bandwidth constraints.
>
> Support for more than 8bpc was added recently in the driver but it
> defaults to the maximum supported bpc - locking out these modes.
>
> This should be a user configurable option such that the user can select
> what bpc configuration they would like.
>
> [How]
> This patch adds support for getting and setting the amdgpu driver
> specific "max bpc" property on the connector.
>
> It also adds support for limiting the output bpc based on the property
> value. The default limitation is the lowest value in the range, 8bpc.
> This was the old value before the range was uncapped.
>
> This patch should be updated/replaced later once common drm support
> for max bpc lands.
Generally good to call out changes for 'v2' here.
>
> Bugzilla: https://bugs.freedesktop.org/108542
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201585
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200645
> Fixes: e03fd3f300f6 ("drm/amd/display: Do not limit color depth to 8bpc")
>
> Signed-off-by: Nicholas Kazlauskas
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 16
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h| 1 +
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index c440d967db57..6b746afc55e7 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2417,8 +2417,15 @@ static void update_stream_scaling_settings(const
> struct drm_display_mode *mode,
> static enum dc_color_depth
> convert_color_depth_from_display_info(const struct drm_connector *connector)
> {
> + struct dm_connector_state *dm_conn_state =
> + to_dm_connector_state(connector->state);
> uint32_t bpc = connector->display_info.bpc;
>
> + /* TODO: Remove this when there's support for max_bpc in drm */
> + if (dm_conn_state && bpc > dm_conn_state->max_bpc)
> + /* Round down to nearest even number. */
> + bpc = dm_conn_state->max_bpc - (dm_conn_state->max_bpc & 1);
> +
> switch (bpc) {
> case 0:
> /*
> @@ -3001,6 +3008,9 @@ int amdgpu_dm_connector_atomic_set_property(struct
> drm_connector *connector,
> } else if (property == adev->mode_info.underscan_property) {
> dm_new_state->underscan_enable = val;
> ret = 0;
> + } else if (property == adev->mode_info.max_bpc_property) {
> + dm_new_state->max_bpc = val;
> + ret = 0;
> } else if (property == adev->mode_info.freesync_property) {
> dm_new_state->freesync_enable = val;
> ret = 0;
> @@ -3049,6 +3059,9 @@ int amdgpu_dm_connector_atomic_get_property(struct
> drm_connector *connector,
> } else if (property == adev->mode_info.underscan_property) {
> *val = dm_state->underscan_enable;
> ret = 0;
> + } else if (property == adev->mode_info.max_bpc_property) {
> + *val = dm_state->max_bpc;
> + ret = 0;
> } else if (property == adev->mode_info.freesync_property) {
> *val = dm_state->freesync_enable;
> ret = 0;
> @@ -3864,6 +3877,9 @@ void amdgpu_dm_connector_init_helper(struct
> amdgpu_display_manager *dm,
> drm_object_attach_property(>base.base,
> adev->mode_info.underscan_vborder_property,
> 0);
> + drm_object_attach_property(>base.base,
> + adev->mode_info.max_bpc_property,
> + 0);
>
> if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 23f2d05cf07e..afcb9842bb45 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -252,6 +252,7 @@ struct dm_connector_state {
> enum amdgpu_rmx_type scaling;
> uint8_t underscan_vborder;
> uint8_t underscan_hborder;
> + uint8_t max_bpc;
> bool underscan_enable;
> bool freesync_enable;
> bool freesync_capable;
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
On 2018-11-12 10:01 a.m., Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: David Airlie
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Matthias Brugger
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Eric Anholt
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Tony Cheng
> Cc: Shirish S
> Cc: Mikita Lipski
> Cc: Bhawanpreet Lakha
> Cc: David Francis
> Cc: Anthony Koo
> Cc: Jeykumar Sankaran
> Cc: Jordan Crouse
> Cc: Bruce Wang
> Cc: Sravanthi Kollukuduru
> Cc: Archit Taneja
> Cc: Steve Kowalik
> Cc: Carsten Behling
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Mahesh Kumar
> Cc: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
For amdgpu_dm and core changes
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--
> drivers/gpu/drm/arm/malidp_crtc.c | 5 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +--
> drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +--
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +---
> drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++--
> drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++--
> drivers/gpu/drm/tegra/dc.c| 5 +--
> drivers/gpu/drm/vc4/vc4_crtc.c| 8 ++---
> drivers/gpu/drm/vkms/vkms_crtc.c | 7 +
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +-
> include/drm/drm_atomic_state_helper.h | 2 ++
> 18 files changed, 56 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5064768642f3..770a71726cd1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2802,9 +2802,7 @@ static void dm_crtc_reset_state(struct drm_crtc *crtc)
> if (WARN_ON(!state))
> return;
>
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> -
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index e1b72782848c..9a924ff27148 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -474,10 +474,7 @@ static void malidp_crtc_reset(struct drm_crtc *crtc)
>
> kfree(state);
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static void malidp_crtc_destroy_state(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 96f4082671fe..8084d549c7d1 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/
Re: [PATCH] drm/amd: update ATIF functions in AMD ACPI header
On 2018-11-08 3:57 p.m., David Francis wrote:
> The ACPI interface in AMD was a few years out of date
> and contained some unused and deprecated functions
>
> Remove functions: Select Active Displays, Get Lid State,
> Get TV Standard, Set TV Standard, Get Panel Expansion Mode,
> Set Panel Expansion Mode, Get Graphics Device Types
>
> Add functions: Query Backlight Transfer Characteristics,
> Ready To Undock Notification
>
> Changed functions: Get System Parameters,
> Get System BIOS Requests
>
> All changes are right from the standard
> ATI ACPI Control Methods V0.44
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 31 ++---
> drivers/gpu/drm/amd/include/amd_acpi.h | 151 +++
> 2 files changed, 56 insertions(+), 126 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> index 7f0afc526419..471266901d1b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> @@ -41,28 +41,21 @@ struct amdgpu_atif_notification_cfg {
> };
>
> struct amdgpu_atif_notifications {
> - bool display_switch;
> - bool expansion_mode_change;
> bool thermal_state;
> bool forced_power_state;
> bool system_power_state;
> - bool display_conf_change;
> - bool px_gfx_switch;
> bool brightness_change;
> bool dgpu_display_event;
> + bool gpu_package_power_limit;
> };
>
> struct amdgpu_atif_functions {
> bool system_params;
> bool sbios_requests;
> - bool select_active_disp;
> - bool lid_state;
> - bool get_tv_standard;
> - bool set_tv_standard;
> - bool get_panel_expansion_mode;
> - bool set_panel_expansion_mode;
> bool temperature_change;
> - bool graphics_device_types;
> + bool query_backlight_transfer_characteristics;
> + bool ready_to_undock;
> + bool external_gpu_information;
> };
>
> struct amdgpu_atif {
> @@ -137,15 +130,12 @@ static union acpi_object *amdgpu_atif_call(struct
> amdgpu_atif *atif,
> */
> static void amdgpu_atif_parse_notification(struct amdgpu_atif_notifications
> *n, u32 mask)
> {
> - n->display_switch = mask & ATIF_DISPLAY_SWITCH_REQUEST_SUPPORTED;
> - n->expansion_mode_change = mask &
> ATIF_EXPANSION_MODE_CHANGE_REQUEST_SUPPORTED;
> n->thermal_state = mask & ATIF_THERMAL_STATE_CHANGE_REQUEST_SUPPORTED;
> n->forced_power_state = mask &
> ATIF_FORCED_POWER_STATE_CHANGE_REQUEST_SUPPORTED;
> n->system_power_state = mask &
> ATIF_SYSTEM_POWER_SOURCE_CHANGE_REQUEST_SUPPORTED;
> - n->display_conf_change = mask &
> ATIF_DISPLAY_CONF_CHANGE_REQUEST_SUPPORTED;
> - n->px_gfx_switch = mask & ATIF_PX_GFX_SWITCH_REQUEST_SUPPORTED;
> n->brightness_change = mask &
> ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST_SUPPORTED;
> n->dgpu_display_event = mask & ATIF_DGPU_DISPLAY_EVENT_SUPPORTED;
> + n->gpu_package_power_limit = mask &
> ATIF_GPU_PACKAGE_POWER_LIMIT_REQUEST_SUPPORTED;
> }
>
> /**
> @@ -162,14 +152,11 @@ static void amdgpu_atif_parse_functions(struct
> amdgpu_atif_functions *f, u32 mas
> {
> f->system_params = mask & ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED;
> f->sbios_requests = mask & ATIF_GET_SYSTEM_BIOS_REQUESTS_SUPPORTED;
> - f->select_active_disp = mask & ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED;
> - f->lid_state = mask & ATIF_GET_LID_STATE_SUPPORTED;
> - f->get_tv_standard = mask & ATIF_GET_TV_STANDARD_FROM_CMOS_SUPPORTED;
> - f->set_tv_standard = mask & ATIF_SET_TV_STANDARD_IN_CMOS_SUPPORTED;
> - f->get_panel_expansion_mode = mask &
> ATIF_GET_PANEL_EXPANSION_MODE_FROM_CMOS_SUPPORTED;
> - f->set_panel_expansion_mode = mask &
> ATIF_SET_PANEL_EXPANSION_MODE_IN_CMOS_SUPPORTED;
> f->temperature_change = mask &
> ATIF_TEMPERATURE_CHANGE_NOTIFICATION_SUPPORTED;
> - f->graphics_device_types = mask &
> ATIF_GET_GRAPHICS_DEVICE_TYPES_SUPPORTED;
> + f->query_backlight_transfer_characteristics =
> + mask & ATIF_QUERY_BACKLIGHT_TRANSFER_CHARACTERISTICS_SUPPORTED;
> + f->ready_to_undock = mask & ATIF_READY_TO_UNDOCK_NOTIFICATION_SUPPORTED;
> + f->external_gpu_information = mask &
> ATIF_GET_EXTERNAL_GPU_INFORMATION_SUPPORTED;
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/include/amd_acpi.h
> b/drivers/gpu/drm/amd/include/amd_acpi.h
> index 9b9699fc433f..89
Re: [PATCH 2/2] drm/amd/display: Support "max_bpc" connector property
On 2018-11-07 9:56 a.m., Nicholas Kazlauskas wrote:
> [Why]
> Many panels support more than 8bpc but some modes are unavailable while
> running at greater than 8bpc due to DP/HDMI bandwidth constraints.
>
> Support for more than 8bpc was added recently in the driver but it's
> defaults to the maximum supported bpc - locking out these modes.
>
> This should be a user configurable option such that the user can select
> what bpc configuration they would like.
>
> [How]
> Add support for getting and setting the property on the connector
> in amdgpu_dm.
>
> The maximum bpc is then limited by the value set by the user. The
> default value is the lowest in the range, 8bpc. This was the old
> default before the range was uncapped.
>
Would be good to have a Fixes tag referencing the regression commit and
Bugzilla tags for all bugzilla bugs that are fixed by this.
Harry
> Signed-off-by: Nicholas Kazlauskas
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index c440d967db57..6184c5bc52e3 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2417,8 +2417,14 @@ static void update_stream_scaling_settings(const
> struct drm_display_mode *mode,
> static enum dc_color_depth
> convert_color_depth_from_display_info(const struct drm_connector *connector)
> {
> + struct dm_connector_state *dm_conn_state =
> + to_dm_connector_state(connector->state);
> uint32_t bpc = connector->display_info.bpc;
>
> + if (dm_conn_state && bpc > dm_conn_state->max_bpc)
> + /* Round down to nearest even number. */
> + bpc = dm_conn_state->max_bpc - (dm_conn_state->max_bpc & 1);
> +
> switch (bpc) {
> case 0:
> /*
> @@ -3001,6 +3007,9 @@ int amdgpu_dm_connector_atomic_set_property(struct
> drm_connector *connector,
> } else if (property == adev->mode_info.underscan_property) {
> dm_new_state->underscan_enable = val;
> ret = 0;
> + } else if (property == adev->mode_info.max_bpc_property) {
> + dm_new_state->max_bpc = val;
> + ret = 0;
> } else if (property == adev->mode_info.freesync_property) {
> dm_new_state->freesync_enable = val;
> ret = 0;
> @@ -3049,6 +3058,9 @@ int amdgpu_dm_connector_atomic_get_property(struct
> drm_connector *connector,
> } else if (property == adev->mode_info.underscan_property) {
> *val = dm_state->underscan_enable;
> ret = 0;
> + } else if (property == adev->mode_info.max_bpc_property) {
> + *val = dm_state->max_bpc;
> + ret = 0;
> } else if (property == adev->mode_info.freesync_property) {
> *val = dm_state->freesync_enable;
> ret = 0;
> @@ -3864,6 +3876,9 @@ void amdgpu_dm_connector_init_helper(struct
> amdgpu_display_manager *dm,
> drm_object_attach_property(>base.base,
> adev->mode_info.underscan_vborder_property,
> 0);
> + drm_object_attach_property(>base.base,
> + adev->mode_info.max_bpc_property,
> + 0);
>
> if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 23f2d05cf07e..afcb9842bb45 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -252,6 +252,7 @@ struct dm_connector_state {
> enum amdgpu_rmx_type scaling;
> uint8_t underscan_vborder;
> uint8_t underscan_hborder;
> + uint8_t max_bpc;
> bool underscan_enable;
> bool freesync_enable;
> bool freesync_capable;
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/2] drm/amdgpu: Add "max_bpc" connector property
On 2018-11-07 9:56 a.m., Nicholas Kazlauskas wrote:
> [Why]
> Many panels support more than 8bpc but some modes are unavailable while
> running at greater than 8bpc due to DP/HDMI bandwidth constraints.
>
> Support for more than 8bpc was added recently in the driver but it's
> defaults to the maximum supported bpc - locking out these modes.
>
> This should be a user configurable option such that the user can select
> what bpc configuration they would like.
>
> [How]
> Introduce the "max_bpc" connector property so the user can limit the
> maximum bpc for the panel. It ranges from 8 to 16.
>
> This doesn't directly set the preferred bpc for the panel but this
> convetion is already in use for other drivers.
covetion -> convention
Maybe mention that this mirrors the behavior used by the i915 driver so people
are not left guessing.
Harry
>
> Signed-off-by: Nicholas Kazlauskas
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 7d6a36bca9dd..83dadf5b85e0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -626,6 +626,11 @@ int amdgpu_display_modeset_create_props(struct
> amdgpu_device *adev)
>"dither",
>amdgpu_dither_enum_list, sz);
>
> + adev->mode_info.max_bpc_property =
> + drm_property_create_range(adev->ddev, 0, "max_bpc", 8, 16);
> + if (!adev->mode_info.max_bpc_property)
> + return -ENOMEM;
> +
> if (amdgpu_device_has_dc_support(adev)) {
> adev->mode_info.freesync_property =
> drm_property_create_bool(adev->ddev, 0, "freesync");
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 1627dd3413c7..c39af5d79608 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -338,6 +338,8 @@ struct amdgpu_mode_info {
> struct drm_property *audio_property;
> /* FMT dithering */
> struct drm_property *dither_property;
> + /* maximum number of bits per channel for monitor color */
> + struct drm_property *max_bpc_property;
> /* it is used to allow enablement of freesync mode */
> struct drm_property *freesync_property;
> /* it is used to know about display capability of freesync mode */
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v6 4/5] drm/amdgpu: Correct get_crtc_scanoutpos behavior when vpos >= vtotal
On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
> When variable refresh rate is active the hardware counter can return
> a position >= vtotal. This results in a vpos being returned from
> amdgpu_display_get_crtc_scanoutpos that's a positive value. The
> positive value indicates to the caller that the display is
> currently in scanout when the display is actually still in vblank.
>
> This is because the vfront porch duration is unknown with variable
> refresh active and will end when either a page flip occurs or the
> timeout specified by the driver/display is reached.
>
> The behavior of the amdgpu_display_get_crtc_scanoutpos remains the
> same when the position is below vtotal. When the position is above
> vtotal the function will return a value that is effectively -vbl_end,
> the size of the vback porch.
>
> The only caller affected by this change is the DRM helper for
> calculating vblank timestamps. This change corrects behavior for
> calculating the page flip timestap from being the previous timestamp
> to the calculation to the next timestamp when position >= vtotal.
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> Cc: Michel Dänzer
> Cc: Harry Wentland
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 6748cd7fc129..cb331319f225 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -850,7 +850,12 @@ int amdgpu_display_get_crtc_scanoutpos(struct drm_device
> *dev,
> /* Inside "upper part" of vblank area? Apply corrective offset if so: */
> if (in_vbl && (*vpos >= vbl_start)) {
> vtotal = mode->crtc_vtotal;
> - *vpos = *vpos - vtotal;
> +
> + /* With variable refresh rate displays the vpos can exceed
> + * the vtotal value. Clamp to 0 to return -vbl_end instead
> + * of guessing the remaining number of lines until scanout.
> + */
> + *vpos = (*vpos < vtotal) ? (*vpos - vtotal) : 0;
> }
>
> /* Correct for shifted end of vbl at vbl_end. */
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v6 3/5] drm: Document variable refresh properties
On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote: > These include the drm_connector 'vrr_capable' and the drm_crtc > 'vrr_enabled' properties. > > Signed-off-by: Nicholas Kazlauskas > Cc: Harry Wentland > Cc: Manasi Navare > Cc: Pekka Paalanen > Cc: Ville Syrjälä > Cc: Michel Dänzer > --- > Documentation/gpu/drm-kms.rst | 7 > drivers/gpu/drm/drm_connector.c | 61 + > 2 files changed, 68 insertions(+) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index 4b1501b4835b..8da2a178cf85 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -575,6 +575,13 @@ Explicit Fencing Properties > .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c > :doc: explicit fencing properties > > + > +Variable Refresh Properties > +--- > + > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c > + :doc: Variable refresh properties > + > Existing KMS Properties > --- > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index 49290060ab7b..a6adf5450db3 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1255,6 +1255,67 @@ int drm_mode_create_scaling_mode_property(struct > drm_device *dev) > } > EXPORT_SYMBOL(drm_mode_create_scaling_mode_property); > > +/** > + * DOC: Variable refresh properties > + * > + * Variable refresh rate capable displays can dynamically adjust their > + * refresh rate by extending the duration of their vertical porch until vertical porch -> vertical front porch > + * page flip or timeout occurs. This can reduce or remove stuttering > + * and latency in scenarios where the page flip does not align with the > + * vblank interval. > + * > + * An example scenario would be an application flipping at a constant rate > + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank > + * interval and the same contents will be displayed twice. This can be > + * observed as stuttering for content with motion. > + * > + * If variable refresh rate was active on a display that supported a > + * variable refresh range from 35Hz to 60Hz no stuttering would be observable > + * for the example scenario. The minimum supported variable refresh rate of > + * 35Hz is below the page flip frequency and the vertical front porch can > + * be extended until the page flip occurs. The vblank interval will be > + * directly aligned to the page flip rate. > + * > + * Userspace control for variable refresh rate is supported via properties > + * on the _connector and _crtc objects. > + * > + * "vrr_capable": > + * Optional _connector boolean property that drivers should attach > + * with drm_connector_attach_vrr_capable_property() on connectors that > + * could support variable refresh rates. Drivers should update the > + * property value by calling drm_connector_set_vrr_capable_property(). > + * > + * Absence of the property should indicate absence of support. > + * > + * "vrr_enabled": > + * Default _crtc boolean property that notifies the driver that the > + * content on the CRTC is suitable for variable refresh rate presentation. > + * The driver will take this property as a hint to enable variable > + * refresh rate support if the receiver supports it, ie. if the > + * "vrr_capable" property is true on the _connector object. The > + * veritcal front porch duration will be extended until page-flip or veritcal -> vertical > + * timeout when enabled. > + * > + * The minimum vertical front porch duration is defined as the vertical > + * front porch duration for the current mode. > + * > + * The maximum vertical front porch duration is greater than or equal to > + * the minimum vertical front porch duration. The duration is derived > + * from the minimum supported variable refresh rate for the connector. > + * > + * The driver may place further restrictions within these minimum > + * and maximum bounds. > + * > + * Some displays may exhibit noticeable differences in brightness when > + * varying vertical front porch duration. > + * Maybe something like this makes sense here: * Some displays may exhibit noticeable differences in brightness when * varying vertical front porch duration drastically. It is therefore * advised userspace only provide the "vrr_enabled" hint for content * with a render rate that is expected to change gradually frame to frame, * such as games. > + * The semantics for the vertical blank timestamp differ when > + * variable refresh rate is active. The vertical blank timestamp > + * is defined to be an estimate using the current mode's fixed > + * refresh rate timings. The semantics for the page-flip event > + * timestamp remain the same. > + */ > + > /** > * drm_connector_attach_vrr_capable_property - creates the > * vrr_capable property >
Re: [PATCH 5/5] drm/amdgpu/display/dce11: only enable FBC when selected
On 2018-11-06 3:29 p.m., Alex Deucher wrote: > Causes a black screen on a Stoney laptop. > > bug: https://bugs.freedesktop.org/show_bug.cgi?id=108577 > Signed-off-by: Alex Deucher Thanks. Series is Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c > b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c > index 1a90e1a38055..e33d11785b1f 100644 > --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c > +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c > @@ -1354,7 +1354,8 @@ static bool construct( > pool->base.sw_i2cs[i] = NULL; > } > > - dc->fbc_compressor = dce110_compressor_create(ctx); > + if (dc->config.fbc_support) > + dc->fbc_compressor = dce110_compressor_create(ctx); > > if (!underlay_create(ctx, >base)) > goto res_create_fail; > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu/vega20: add CLK base offset
On 2018-11-06 11:24 a.m., Alex Deucher wrote: > In case we need to access CLK registers. > > Signed-off-by: Alex Deucher Acked-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c > b/drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c > index 2d4473557b0d..d13fc4fcb517 100644 > --- a/drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c > +++ b/drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c > @@ -49,6 +49,7 @@ int vega20_reg_base_init(struct amdgpu_device *adev) > adev->reg_offset[SMUIO_HWIP][i] = (uint32_t > *)(&(SMUIO_BASE.instance[i])); > adev->reg_offset[NBIF_HWIP][i] = (uint32_t > *)(&(NBIO_BASE.instance[i])); > adev->reg_offset[THM_HWIP][i] = (uint32_t > *)(&(THM_BASE.instance[i])); > + adev->reg_offset[CLK_HWIP][i] = (uint32_t > *)(&(CLK_BASE.instance[i])); > } > return 0; > } > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd: Don't fail on backlight = 0
On 2018-11-06 11:14 a.m., David Francis wrote:
> Amgpu's backlight update status function was
> returning 1 (an error value) when the backlight
> property was 0. This breaks users that assume
> 0 is a valid backlight value (which is a
> correct assumption)
>
> If the user passes in a backlight value of 0,
> tell them everything is fine, then write a value of
> 1 to hardware.
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> Bugzilla: https://bugs.freedesktop.org/108668
> Fixes: 416615ea9578 ("drm/amd/display: set backlight level limit to 1")
> Cc: suresh.gutt...@amd.com
> Cc: harry.wentl...@amd.com
> Cc: samant...@posteo.net
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index f8ec8a146663..131e6483d442 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1567,21 +1567,23 @@ static int amdgpu_dm_backlight_update_status(struct
> backlight_device *bd)
> {
> struct amdgpu_display_manager *dm = bl_get_data(bd);
>
> + /* backlight_pwm_u16_16 parameter is in unsigned 32 bit, 16 bit integer
> + * and 16 bit fractional, where 1.0 is max backlight value.
> + * bd->props.brightness is 8 bit format and needs to be converted by
> + * scaling via copy lower byte to upper byte of 16 bit value.
> + */
> + uint32_t brightness = bd->props.brightness * 0x101;
> +
> /*
>* PWM interperts 0 as 100% rather than 0% because of HW
> - * limitation for level 0.So limiting minimum brightness level
> + * limitation for level 0. So limiting minimum brightness level
>* to 1.
>*/
> if (bd->props.brightness < 1)
> - return 1;
> + brightness = 0x101;
>
> - /* backlight_pwm_u16_16 parameter is in unsigned 32 bit, 16 bit integer
> - * and 16 bit fractional, where 1.0 is max backlight value.
> - * bd->props.brightness is 8 bit format and needs to be converted by
> - * scaling via copy lower byte to upper byte of 16 bit value.
> - */
> if (dc_link_set_backlight_level(dm->backlight_link,
> - (bd->props.brightness * 0x101), 0, 0))
> + brightness, 0, 0))
> return 0;
> else
> return 1;
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v3 3/3] drm/amdgpu: Change powerplay clock requests to MHz
On 2018-11-02 9:26 a.m., David Francis wrote:
> This will clean up powerplay code, as we are no longer
> multiplying the clocks by 1000 in DM and then dividing them
> by 1000 in powerplay
>
> Signed-off-by: David Francis
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 6 +++---
> drivers/gpu/drm/amd/include/dm_pp_interface.h| 2 +-
> drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c| 4 ++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 4 ++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 4 ++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 4 ++--
> 6 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> index d9daa038fdb2..cfa9b7f545b8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> @@ -436,7 +436,7 @@ bool dm_pp_apply_clock_for_voltage_request(
> int ret = 0;
>
> pp_clock_request.clock_type =
> dc_to_pp_clock_type(clock_for_voltage_req->clk_type);
> - pp_clock_request.clock_freq_in_khz =
> clock_for_voltage_req->clocks_in_khz;
> + pp_clock_request.clock_freq_in_mhz =
> clock_for_voltage_req->clocks_in_khz / 1000;
>
> if (!pp_clock_request.clock_type)
> return false;
> @@ -485,11 +485,11 @@ void pp_rv_set_display_requirement(struct pp_smu *pp,
> return;
>
> clock.clock_type = amd_pp_dcf_clock;
> - clock.clock_freq_in_khz = req->hard_min_dcefclk_mhz * 1000;
> + clock.clock_freq_in_mhz = req->hard_min_dcefclk_mhz;
> pp_funcs->display_clock_voltage_request(pp_handle, );
>
> clock.clock_type = amd_pp_f_clock;
> - clock.clock_freq_in_khz = req->hard_min_fclk_mhz * 1000;
> + clock.clock_freq_in_mhz = req->hard_min_fclk_mhz;
> pp_funcs->display_clock_voltage_request(pp_handle, );
> }
>
> diff --git a/drivers/gpu/drm/amd/include/dm_pp_interface.h
> b/drivers/gpu/drm/amd/include/dm_pp_interface.h
> index 1d93a0c574c9..114ddd03e238 100644
> --- a/drivers/gpu/drm/amd/include/dm_pp_interface.h
> +++ b/drivers/gpu/drm/amd/include/dm_pp_interface.h
> @@ -188,7 +188,7 @@ struct pp_clock_levels_with_voltage {
>
> struct pp_display_clock_request {
> enum amd_pp_clock_type clock_type;
> - uint32_t clock_freq_in_khz;
> + uint32_t clock_freq_in_mhz;
> };
>
> #endif /* _DM_PP_INTERFACE_ */
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> index dd18cb710391..d6a6a4f4ac9d 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> @@ -57,7 +57,7 @@ static int smu10_display_clock_voltage_request(struct
> pp_hwmgr *hwmgr,
> {
> struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr *)(hwmgr->backend);
> enum amd_pp_clock_type clk_type = clock_req->clock_type;
> - uint32_t clk_freq = clock_req->clock_freq_in_khz / 1000;
> + uint32_t clk_freq = clock_req->clock_freq_in_mhz;
> PPSMC_Msgmsg;
>
> switch (clk_type) {
> @@ -203,7 +203,7 @@ static int smu10_set_clock_limit(struct pp_hwmgr *hwmgr,
> const void *input)
>
> clocks.dcefClock = hwmgr->display_config->min_dcef_set_clk;
> clock_req.clock_type = amd_pp_dcf_clock;
> - clock_req.clock_freq_in_khz = clocks.dcefClock * 10;
> + clock_req.clock_freq_in_mhz = clocks.dcefClock / 100;
>
> PP_ASSERT_WITH_CODE(!smu10_display_clock_voltage_request(hwmgr,
> _req),
> "Attempt to set DCF Clock Failed!", return
> -EINVAL);
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index 8c4db86bb4b7..b1ea1e074373 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -3770,7 +3770,7 @@ int vega10_display_clock_voltage_request(struct
> pp_hwmgr *hwmgr,
> {
> int result = 0;
> enum amd_pp_clock_type clk_type = clock_req->clock_type;
> - uint32_t clk_freq = clock_req->clock_freq_in_khz / 1000;
> + uint32_t clk_freq = clock_req->clock_freq_in_mhz;
> DSPCLK_e clk_select = 0;
> uint32_t clk_request = 0;
>
> @@ -3855,7 +3855,7 @@ static int
> vega10_notify_smc_display_config_after_ps_adjustment(
>
> if (i < dp
Re: [PATCH 2/2] drm/amdgpu/display: disable FBC
On 2018-11-05 2:27 p.m., Alex Deucher wrote: > Causes a black screen on Stoney laptop. > > bug: https://bugs.freedesktop.org/show_bug.cgi?id=108577 > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c > b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c > index 1a90e1a38055..ad59436a91b1 100644 > --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c > +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c > @@ -1354,7 +1354,8 @@ static bool construct( > pool->base.sw_i2cs[i] = NULL; > } > > - dc->fbc_compressor = dce110_compressor_create(ctx); > + /* disable FBC for now */ > + /* dc->fbc_compressor = dce110_compressor_create(ctx); */ Maybe we should make that runtime configurable if it can be flaky, like i915's enable_fbc: https://wiki.archlinux.org/index.php/intel_graphics#Framebuffer_compression_.28enable_fbc.29 Harry > > if (!underlay_create(ctx, >base)) > goto res_create_fail; > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/2] drm/amdgpu/display: check if fbc is available in set_static_screen_control
On 2018-11-05 2:27 p.m., Alex Deucher wrote:
> The value is dependent on whether fbc is available.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
> index 4789270c29d9..6c9299e33f34 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
> @@ -1738,6 +1738,7 @@ static void get_position(struct pipe_ctx **pipe_ctx,
> static void set_static_screen_control(struct pipe_ctx **pipe_ctx,
> int num_pipes, const struct dc_static_screen_events *events)
> {
> + struct dc *dc = pipe_ctx[0]->stream->ctx->dc;
pipe_ctx[0] could be undefined if num_pipes == 0. I don't think this should
happen but I can see a bunch of ways dc_stream_set_static_screen_events might
call this with num_pipes=0. Maybe best to guard against it.
Harry
> unsigned int i;
> unsigned int value = 0;
>
> @@ -1750,7 +1751,8 @@ static void set_static_screen_control(struct pipe_ctx
> **pipe_ctx,
> if (events->force_trigger)
> value |= 0x1;
>
> - value |= 0x84;
> + if (dc->fbc_compressor)
> + value |= 0x84;
>
> for (i = 0; i < num_pipes; i++)
> pipe_ctx[i]->stream_res.tg->funcs->
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/amdgpu/dm: Fix dm_dp_create_fake_mst_encoder()
On 2018-11-01 9:51 p.m., Lyude Paul wrote: > [why] > Removing connector reusage from DM to match the rest of the tree ended > up revealing an issue that was surprisingly subtle. The original amdgpu > code for DC that was submitted appears to have left a chunk in > dm_dp_create_fake_mst_encoder() that tries to find a "master encoder", > the likes of which isn't actually used or stored anywhere. It does so at > the wrong time as well by trying to access parts of the drm_connector > from the encoder init before it's actually been initialized. This > results in a NULL pointer deref on MST hotplugs: > > [ 160.696613] BUG: unable to handle kernel NULL pointer dereference at > > [ 160.697234] PGD 0 P4D 0 > [ 160.697814] Oops: 0010 [#1] SMP PTI > [ 160.698430] CPU: 2 PID: 64 Comm: kworker/2:1 Kdump: loaded Tainted: G > O 4.19.0Lyude-Test+ #2 > [ 160.699020] Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.22 > 05/17/2018 > [ 160.699672] Workqueue: events_long drm_dp_mst_link_probe_work > [drm_kms_helper] > [ 160.700322] RIP: 0010: (null) > [ 160.700920] Code: Bad RIP value. > [ 160.701541] RSP: 0018:c929fc78 EFLAGS: 00010206 > [ 160.702183] RAX: RBX: 8804440ed468 RCX: > 8804440e9158 > [ 160.702778] RDX: RSI: 8804556c5700 RDI: > 8804440ed000 > [ 160.703408] RBP: 880458e21800 R08: 0002 R09: > 5fca0a25 > [ 160.704002] R10: 88045a077a3d R11: 88045a077a3c R12: > 8804440ed000 > [ 160.704614] R13: 880458e21800 R14: 8804440e9000 R15: > 8804440e9000 > [ 160.705260] FS: () GS:88045f28() > knlGS: > [ 160.705854] CS: 0010 DS: ES: CR0: 80050033 > [ 160.706478] CR2: ffd6 CR3: 0200a001 CR4: > 003606e0 > [ 160.707124] DR0: DR1: DR2: > > [ 160.707724] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 160.708372] Call Trace: > [ 160.708998] ? dm_dp_add_mst_connector+0xed/0x1d0 [amdgpu] > [ 160.709625] ? drm_dp_add_port+0x2fa/0x470 [drm_kms_helper] > [ 160.710284] ? wake_up_q+0x54/0x70 > [ 160.710877] ? __mutex_unlock_slowpath.isra.18+0xb3/0x110 > [ 160.711512] ? drm_dp_dpcd_access+0xe7/0x110 [drm_kms_helper] > [ 160.712161] ? drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] > [ 160.712762] ? drm_dp_check_and_send_link_address+0xa3/0xd0 > [drm_kms_helper] > [ 160.713408] ? drm_dp_mst_link_probe_work+0x4b/0x80 [drm_kms_helper] > [ 160.714013] ? process_one_work+0x1a1/0x3a0 > [ 160.714667] ? worker_thread+0x30/0x380 > [ 160.715326] ? wq_update_unbound_numa+0x10/0x10 > [ 160.715939] ? kthread+0x112/0x130 > [ 160.716591] ? kthread_create_worker_on_cpu+0x70/0x70 > [ 160.717262] ? ret_from_fork+0x35/0x40 > [ 160.717886] Modules linked in: amdgpu(O) vfat fat snd_hda_codec_generic > joydev i915 chash gpu_sched ttm i2c_algo_bit drm_kms_helper > snd_hda_codec_hdmi hp_wmi syscopyarea iTCO_wdt sysfillrect sparse_keymap > sysimgblt fb_sys_fops snd_hda_intel usbhid wmi_bmof drm snd_hda_codec btusb > snd_hda_core intel_rapl btrtl x86_pkg_temp_thermal btbcm btintel coretemp > snd_pcm crc32_pclmul bluetooth psmouse snd_timer snd pcspkr i2c_i801 mei_me > i2c_core soundcore mei tpm_tis wmi tpm_tis_core hp_accel ecdh_generic > lis3lv02d tpm video rfkill acpi_pad input_polldev hp_wireless pcc_cpufreq > crc32c_intel serio_raw tg3 xhci_pci xhci_hcd [last unloaded: amdgpu] > [ 160.720141] CR2: > > Somehow the connector reusage DM was using for MST connectors managed to > paper over this issue entirely; hence why this was never caught until > now. > > [how] > Since this code isn't used anywhere and seems useless anyway, we can > just drop it entirely. This appears to fix the issue on my HP ZBook with > an AMD WX4150. > > Signed-off-by: Lyude Paul Good catch. Probably got broken with some of the best_encoder cleanup that happened in the last few months. I really should've caught it then. Reviewed-by: Harry Wentland Harry > --- > Hey! This is the patch that I was talking about, feel free to review > it-we should make sure this goes in with the rest of the patches you've > got so far. > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c > index 6aa7359d61a3..5432a1862b41 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c > +++ b/driver
Re: [PATCH 2/2] drm/amdgpu: Change pp clock requests to mHz
On 2018-10-30 3:34 p.m., David Francis wrote:
> We were multiplying clock requests by 1000 in amdgpu_dm
> and then dividing them by 1000 in powerplay.
>
> Also, the vega12 code was dividing by 10 when it should have been
> multiplying (to convert units of 10kHz to units of kHz).
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 6 +++---
> drivers/gpu/drm/amd/include/dm_pp_interface.h| 2 +-
> drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c| 4 ++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 4 ++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 4 ++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 4 ++--
> 6 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> index d9daa038fdb2..cfa9b7f545b8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> @@ -436,7 +436,7 @@ bool dm_pp_apply_clock_for_voltage_request(
> int ret = 0;
>
> pp_clock_request.clock_type =
> dc_to_pp_clock_type(clock_for_voltage_req->clk_type);
> - pp_clock_request.clock_freq_in_khz =
> clock_for_voltage_req->clocks_in_khz;
> + pp_clock_request.clock_freq_in_mhz =
> clock_for_voltage_req->clocks_in_khz / 1000;
>
> if (!pp_clock_request.clock_type)
> return false;
> @@ -485,11 +485,11 @@ void pp_rv_set_display_requirement(struct pp_smu *pp,
> return;
>
> clock.clock_type = amd_pp_dcf_clock;
> - clock.clock_freq_in_khz = req->hard_min_dcefclk_mhz * 1000;
> + clock.clock_freq_in_mhz = req->hard_min_dcefclk_mhz;
> pp_funcs->display_clock_voltage_request(pp_handle, );
>
> clock.clock_type = amd_pp_f_clock;
> - clock.clock_freq_in_khz = req->hard_min_fclk_mhz * 1000;
> + clock.clock_freq_in_mhz = req->hard_min_fclk_mhz;
> pp_funcs->display_clock_voltage_request(pp_handle, );
> }
>
> diff --git a/drivers/gpu/drm/amd/include/dm_pp_interface.h
> b/drivers/gpu/drm/amd/include/dm_pp_interface.h
> index 1d93a0c574c9..114ddd03e238 100644
> --- a/drivers/gpu/drm/amd/include/dm_pp_interface.h
> +++ b/drivers/gpu/drm/amd/include/dm_pp_interface.h
> @@ -188,7 +188,7 @@ struct pp_clock_levels_with_voltage {
>
> struct pp_display_clock_request {
> enum amd_pp_clock_type clock_type;
> - uint32_t clock_freq_in_khz;
> + uint32_t clock_freq_in_mhz;
> };
>
> #endif /* _DM_PP_INTERFACE_ */
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> index dd18cb710391..d6a6a4f4ac9d 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> @@ -57,7 +57,7 @@ static int smu10_display_clock_voltage_request(struct
> pp_hwmgr *hwmgr,
> {
> struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr *)(hwmgr->backend);
> enum amd_pp_clock_type clk_type = clock_req->clock_type;
> - uint32_t clk_freq = clock_req->clock_freq_in_khz / 1000;
> + uint32_t clk_freq = clock_req->clock_freq_in_mhz;
> PPSMC_Msgmsg;
>
> switch (clk_type) {
> @@ -203,7 +203,7 @@ static int smu10_set_clock_limit(struct pp_hwmgr *hwmgr,
> const void *input)
>
> clocks.dcefClock = hwmgr->display_config->min_dcef_set_clk;
> clock_req.clock_type = amd_pp_dcf_clock;
> - clock_req.clock_freq_in_khz = clocks.dcefClock * 10;
> + clock_req.clock_freq_in_mhz = clocks.dcefClock / 100;
>
> PP_ASSERT_WITH_CODE(!smu10_display_clock_voltage_request(hwmgr,
> _req),
> "Attempt to set DCF Clock Failed!", return
> -EINVAL);
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index 419a1d77d661..f926a46bf256 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -3740,7 +3740,7 @@ int vega10_display_clock_voltage_request(struct
> pp_hwmgr *hwmgr,
> {
> int result = 0;
> enum amd_pp_clock_type clk_type = clock_req->clock_type;
> - uint32_t clk_freq = clock_req->clock_freq_in_khz / 1000;
> + uint32_t clk_freq = clock_req->clock_freq_in_mhz;
> DSPCLK_e clk_select = 0;
> uint32_t clk_request = 0;
>
> @@ -3825,7 +3825,7 @@ static int
> vega10_no
Re: [PATCH 2/2] drm/amd/display: Drop reusing drm connector for MST
On 2018-10-30 6:09 p.m., Jerry (Fangzhi) Zuo wrote:
> [why]
> It is not safe to keep existing connector while entire topology
> has been removed. Could lead potential impact to uapi.
> Entirely unregister all the connectors on the topology,
> and use a new set of connectors when the topology is plugged back
> on.
>
> [How]
> Remove the drm connector entirely each time when the
> corresponding MST topology is gone.
> When hotunplug a connector (e.g., DP2)
> 1. Remove connector from userspace.
> 2. Drop it's reference.
> When hotplug back on:
> 1. Detect new topology, and create new connectors.
> 2. Notify userspace with sysfs hotplug event.
> 3. Reprobe new connectors, and reassign CRTC from old (e.g., DP2)
> to new (e.g., DP3) connector.
>
> Signed-off-by: Jerry (Fangzhi) Zuo
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 --
> .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 40
> --
> 2 files changed, 7 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 101e122945a4..23f2d05cf07e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -208,8 +208,6 @@ struct amdgpu_dm_connector {
> struct mutex hpd_lock;
>
> bool fake_enable;
> -
> - bool mst_connected;
> };
>
> #define to_amdgpu_dm_connector(x) container_of(x, struct
> amdgpu_dm_connector, base)
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 744d97cc0d39..621afe39de13 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -320,25 +320,6 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
> *mgr,
> struct amdgpu_device *adev = dev->dev_private;
> struct amdgpu_dm_connector *aconnector;
> struct drm_connector *connector;
> - struct drm_connector_list_iter conn_iter;
> -
> - drm_connector_list_iter_begin(dev, _iter);
> - drm_for_each_connector_iter(connector, _iter) {
> - aconnector = to_amdgpu_dm_connector(connector);
> - if (aconnector->mst_port == master
> - && !aconnector->port) {
> - DRM_INFO("DM_MST: reusing connector: %p [id: %d]
> [master: %p]\n",
> - aconnector, connector->base.id,
> aconnector->mst_port);
> -
> - aconnector->port = port;
> - drm_connector_set_path_property(connector, pathprop);
> -
> - drm_connector_list_iter_end(_iter);
> - aconnector->mst_connected = true;
> - return >base;
> - }
> - }
> - drm_connector_list_iter_end(_iter);
>
> aconnector = kzalloc(sizeof(*aconnector), GFP_KERNEL);
> if (!aconnector)
> @@ -387,8 +368,6 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
> *mgr,
>*/
> amdgpu_dm_connector_funcs_reset(connector);
>
> - aconnector->mst_connected = true;
> -
> DRM_INFO("DM_MST: added connector: %p [id: %d] [master: %p]\n",
> aconnector, connector->base.id, aconnector->mst_port);
>
> @@ -400,6 +379,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
> *mgr,
> static void dm_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_connector *connector)
> {
> + struct amdgpu_dm_connector *master = container_of(mgr, struct
> amdgpu_dm_connector, mst_mgr);
> + struct drm_device *dev = master->base.dev;
> + struct amdgpu_device *adev = dev->dev_private;
> struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(connector);
>
> DRM_INFO("DM_MST: Disabling connector: %p [id: %d] [master: %p]\n",
> @@ -413,7 +395,10 @@ static void dm_dp_destroy_mst_connector(struct
> drm_dp_mst_topology_mgr *mgr,
> aconnector->dc_sink = NULL;
> }
>
> - aconnector->mst_connected = false;
> + drm_connector_unregister(connector);
> + if (adev->mode_info.rfbdev)
> +
> drm_fb_helper_remove_one_connector(>mode_info.rfbdev->helper,
> connector);
> + drm_connector_unreference(connector);
> }
>
> static void dm_dp_mst_hotplug(struct drm
Re: [PATCH 2/2] drm/amdgpu: Change pp clock requests to mHz
On 2018-10-30 3:34 p.m., David Francis wrote:
> We were multiplying clock requests by 1000 in amdgpu_dm
> and then dividing them by 1000 in powerplay.
>
> Also, the vega12 code was dividing by 10 when it should have been
> multiplying (to convert units of 10kHz to units of kHz).
>
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 6 +++---
> drivers/gpu/drm/amd/include/dm_pp_interface.h| 2 +-
> drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c| 4 ++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 4 ++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 4 ++--
> drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 4 ++--
> 6 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> index d9daa038fdb2..cfa9b7f545b8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> @@ -436,7 +436,7 @@ bool dm_pp_apply_clock_for_voltage_request(
> int ret = 0;
>
> pp_clock_request.clock_type =
> dc_to_pp_clock_type(clock_for_voltage_req->clk_type);
> - pp_clock_request.clock_freq_in_khz =
> clock_for_voltage_req->clocks_in_khz;
> + pp_clock_request.clock_freq_in_mhz =
> clock_for_voltage_req->clocks_in_khz / 1000;
>
> if (!pp_clock_request.clock_type)
> return false;
> @@ -485,11 +485,11 @@ void pp_rv_set_display_requirement(struct pp_smu *pp,
> return;
>
> clock.clock_type = amd_pp_dcf_clock;
> - clock.clock_freq_in_khz = req->hard_min_dcefclk_mhz * 1000;
> + clock.clock_freq_in_mhz = req->hard_min_dcefclk_mhz;
> pp_funcs->display_clock_voltage_request(pp_handle, );
>
> clock.clock_type = amd_pp_f_clock;
> - clock.clock_freq_in_khz = req->hard_min_fclk_mhz * 1000;
> + clock.clock_freq_in_mhz = req->hard_min_fclk_mhz;
> pp_funcs->display_clock_voltage_request(pp_handle, );
> }
>
> diff --git a/drivers/gpu/drm/amd/include/dm_pp_interface.h
> b/drivers/gpu/drm/amd/include/dm_pp_interface.h
> index 1d93a0c574c9..114ddd03e238 100644
> --- a/drivers/gpu/drm/amd/include/dm_pp_interface.h
> +++ b/drivers/gpu/drm/amd/include/dm_pp_interface.h
> @@ -188,7 +188,7 @@ struct pp_clock_levels_with_voltage {
>
> struct pp_display_clock_request {
> enum amd_pp_clock_type clock_type;
> - uint32_t clock_freq_in_khz;
> + uint32_t clock_freq_in_mhz;
> };
>
> #endif /* _DM_PP_INTERFACE_ */
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> index dd18cb710391..d6a6a4f4ac9d 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> @@ -57,7 +57,7 @@ static int smu10_display_clock_voltage_request(struct
> pp_hwmgr *hwmgr,
> {
> struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr *)(hwmgr->backend);
> enum amd_pp_clock_type clk_type = clock_req->clock_type;
> - uint32_t clk_freq = clock_req->clock_freq_in_khz / 1000;
> + uint32_t clk_freq = clock_req->clock_freq_in_mhz;
> PPSMC_Msgmsg;
>
> switch (clk_type) {
> @@ -203,7 +203,7 @@ static int smu10_set_clock_limit(struct pp_hwmgr *hwmgr,
> const void *input)
>
> clocks.dcefClock = hwmgr->display_config->min_dcef_set_clk;
> clock_req.clock_type = amd_pp_dcf_clock;
> - clock_req.clock_freq_in_khz = clocks.dcefClock * 10;
> + clock_req.clock_freq_in_mhz = clocks.dcefClock / 100;
>
> PP_ASSERT_WITH_CODE(!smu10_display_clock_voltage_request(hwmgr,
> _req),
> "Attempt to set DCF Clock Failed!", return
> -EINVAL);
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index 419a1d77d661..f926a46bf256 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -3740,7 +3740,7 @@ int vega10_display_clock_voltage_request(struct
> pp_hwmgr *hwmgr,
> {
> int result = 0;
> enum amd_pp_clock_type clk_type = clock_req->clock_type;
> - uint32_t clk_freq = clock_req->clock_freq_in_khz / 1000;
> + uint32_t clk_freq = clock_req->clock_freq_in_mhz;
> DSPCLK_e clk_select = 0;
> uint32_t clk_request = 0;
>
> @@ -3825,7 +3825,7 @@ static int
> vega10_notify_smc_display_config_after_ps_adjustment(
>
> if (i < dpm_table->count) {
> clock_req.clock_type = amd_pp_dcef_clock;
> - clock_req.clock_freq_in_khz = dpm_table->dpm_levels[i].value *
> 10;
> + clock_req.clock_freq_in_mhz = dpm_table->dpm_levels[i].value /
> 100;
> if (!vega10_display_clock_voltage_request(hwmgr, _req)) {
>
Re: [PATCH] drm/amd/display: set backlight level limit to 1
On 2018-10-26 2:44 a.m., Guttula, Suresh wrote:
>
>
> On 10/26/2018 12:04 AM, Wentland, Harry wrote:
>> On 2018-10-25 2:58 a.m., Guttula, Suresh wrote:
>>> This patch will work as workaround for silicon limitation
>>> related to PWM dutycycle when the backlight level goes to 0.
>>>
>>> Actually PWM value is 16 bit value and valid range from 1-65535.
>>> when ever user requested to set this PWM value to 0 which is not
>>> fall in the range, in VBIOS taken care this by limiting to 1.
>>> This patch here will do the same. Either driver or VBIOS can not
>>> pass 0 value as it is not a valid range for PWM and it will
>>> give a high PWM pulse which is not the intented behaviour as
>>> per HW constraints.
>>>
>>
>>
>> Comments from Windows dev, Anthony, CCed here as well:
>>> In Windows, we typically never set backlight PWM value to 0.
>>> Windows brightness slider is from 0 - 100% brightness.
>>> 0% brightness maps to some non-zero value. So user never gets the chance to
>>> set value to 0.
>>>
>>> I'm not 100% sure what kind of flashing they are seeing.
>>> I thought 0 PWM works, and just means PWM signal always low, I think it
>>> would equate to panel backlight completely being off.
>>> I do know of a flashing issue caused by fractional PWM at low PWM values,
>>> but this would not even be at 0. The flashing problem would be anywhere
>>> from 1 - 300 for example. (out of 65535)
>>
>> Do you see flickering when value is at 0 or in the 1 > 0 transition? 1 would
>> be 65535/256 = 256 and put us right in the 1-300 range that has a flashing
>> problem.
>>
>> Harry
>>
>
> We can not make out if flicker is at transition from 1 to 0 or exactly
> at 0, because the flickering is very instantaneous.But, I am not able to
> see the issue @1 , only seen the issue after going down from 1.
>
Apparently Windows driver also checks ACPI ATIF, VBIOS, and the Windows
registry for backlight range information. When no info is present it limits
backlight to the 12-255 range. We might want to implement the ATIF and VBIOS
checks on amdgpu as well, but for now I think your fix is good.
Reviewed-by: Harry Wentland
Harry
> Thanks,
> Suresh G
>
>>> Signed-off-by: suresh guttula
>>> ---
>>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> index 492230c..38f84b2 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -1518,6 +1518,14 @@ static int amdgpu_dm_backlight_update_status(struct
>>> backlight_device *bd)
>>> {
>>> struct amdgpu_display_manager *dm = bl_get_data(bd);
>>>
>>> + /*
>>> +* When we use brightness low key to reduce the brightness,
>>> +* brightness level reaching to 0, with which we can see flash
>>> +* screen on ui beacuse of HW limitation.To avoid that we are
>>> +* limiting level to 1
>>> +*/
>>> + if (bd->props.brightness < 1)
>>> + return 1;
>>> if (dc_link_set_backlight_level(dm->backlight_link,
>>> bd->props.brightness, 0, 0))
>>> return 0;
>>>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: set backlight level limit to 1
On 2018-10-25 2:58 a.m., Guttula, Suresh wrote:
> This patch will work as workaround for silicon limitation
> related to PWM dutycycle when the backlight level goes to 0.
>
> Actually PWM value is 16 bit value and valid range from 1-65535.
> when ever user requested to set this PWM value to 0 which is not
> fall in the range, in VBIOS taken care this by limiting to 1.
> This patch here will do the same. Either driver or VBIOS can not
> pass 0 value as it is not a valid range for PWM and it will
> give a high PWM pulse which is not the intented behaviour as
> per HW constraints.
>
Comments from Windows dev, Anthony, CCed here as well:
> In Windows, we typically never set backlight PWM value to 0.
> Windows brightness slider is from 0 - 100% brightness.
> 0% brightness maps to some non-zero value. So user never gets the chance to
> set value to 0.
>
> I'm not 100% sure what kind of flashing they are seeing.
> I thought 0 PWM works, and just means PWM signal always low, I think it would
> equate to panel backlight completely being off.
> I do know of a flashing issue caused by fractional PWM at low PWM values, but
> this would not even be at 0. The flashing problem would be anywhere from 1 -
> 300 for example. (out of 65535)
Do you see flickering when value is at 0 or in the 1 > 0 transition? 1 would be
65535/256 = 256 and put us right in the 1-300 range that has a flashing problem.
Harry
> Signed-off-by: suresh guttula
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 492230c..38f84b2 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1518,6 +1518,14 @@ static int amdgpu_dm_backlight_update_status(struct
> backlight_device *bd)
> {
> struct amdgpu_display_manager *dm = bl_get_data(bd);
>
> + /*
> + * When we use brightness low key to reduce the brightness,
> + * brightness level reaching to 0, with which we can see flash
> + * screen on ui beacuse of HW limitation.To avoid that we are
> + * limiting level to 1
> + */
> + if (bd->props.brightness < 1)
> + return 1;
> if (dc_link_set_backlight_level(dm->backlight_link,
> bd->props.brightness, 0, 0))
> return 0;
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v5 4/4] drm/amdgpu: Set FreeSync state using drm VRR properties
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Support for AMDGPU specific FreeSync properties and ioctls are dropped
> from amdgpu_dm in favor of supporting drm variable refresh rate
> properties.
>
> The notify_freesync and set_freesync_property functions are dropped
> from amdgpu_display_funcs.
>
> The drm vrr_capable property is now attached to any DP/HDMI connector.
> Its value is updated accordingly to the connector's FreeSync capabiltiy.
>
> The freesync_enable logic and ioctl control has has been dropped in
> favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
> fine grained atomic control over which CRTCs should support variable
> refresh rate.
>
> To handle state changes for vrr_enabled it was easiest to drop the
> forced modeset on freesync_enabled change. This patch now performs the
> required stream updates when planes are flipped.
>
> This is done for a few reasons:
>
> (1) VRR stream updates can be done in the fast update path
>
> (2) amdgpu_dm_atomic_check would need to be hacked apart to check
> desired variable refresh state and capability before the CRTC
> disable pass.
>
> (3) Performing VRR stream updates on-flip is needed for enabling BTR
> support.
>
> VRR packets and timing adjustments are now tracked and compared to
> previous values sent to the hardware.
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 7 -
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 255 +-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +-
> 3 files changed, 138 insertions(+), 131 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index b9e9e8b02fb7..0cbe867ec375 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -295,13 +295,6 @@ struct amdgpu_display_funcs {
> uint16_t connector_object_id,
> struct amdgpu_hpd *hpd,
> struct amdgpu_router *router);
> - /* it is used to enter or exit into free sync mode */
> - int (*notify_freesync)(struct drm_device *dev, void *data,
> -struct drm_file *filp);
> - /* it is used to allow enablement of freesync mode */
> - int (*set_freesync_property)(struct drm_connector *connector,
> - struct drm_property *property,
> - uint64_t val);
>
>
> };
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e224f23e2215..f6af388cc32d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1802,72 +1802,6 @@ static void dm_bandwidth_update(struct amdgpu_device
> *adev)
> /* TODO: implement later */
> }
>
> -static int amdgpu_notify_freesync(struct drm_device *dev, void *data,
> - struct drm_file *filp)
> -{
> - struct drm_atomic_state *state;
> - struct drm_modeset_acquire_ctx ctx;
> - struct drm_crtc *crtc;
> - struct drm_connector *connector;
> - struct drm_connector_state *old_con_state, *new_con_state;
> - int ret = 0;
> - uint8_t i;
> - bool enable = false;
> -
> - drm_modeset_acquire_init(, 0);
> -
> - state = drm_atomic_state_alloc(dev);
> - if (!state) {
> - ret = -ENOMEM;
> - goto out;
> - }
> - state->acquire_ctx =
> -
> -retry:
> - drm_for_each_crtc(crtc, dev) {
> - ret = drm_atomic_add_affected_connectors(state, crtc);
> - if (ret)
> - goto fail;
> -
> - /* TODO rework amdgpu_dm_commit_planes so we don't need this */
> - ret = drm_atomic_add_affected_planes(state, crtc);
> - if (ret)
> - goto fail;
> - }
> -
> - for_each_oldnew_connector_in_state(state, connector, old_con_state,
> new_con_state, i) {
> - struct dm_connector_state *dm_new_con_state =
> to_dm_connector_state(new_con_state);
> - struct drm_crtc_state *new_crtc_state;
> - struct amdgpu_crtc *acrtc =
> to_amdgpu_crtc(dm_new_con_state->base.crtc);
> - struct dm_crtc_state *dm_new_crtc_state;
> -
> - if (!acrtc) {
> - ASSERT(0);
> - continue;
> - }
> -
> - new_crtc_state = drm_ato
Re: [PATCH v5 3/4] drm: Document variable refresh properties
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote: > These include the drm_connector 'vrr_capable' and the drm_crtc > 'vrr_enabled' properties. > > Signed-off-by: Nicholas Kazlauskas > --- > Documentation/gpu/drm-kms.rst | 7 +++ > drivers/gpu/drm/drm_connector.c | 22 ++ > 2 files changed, 29 insertions(+) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index 4b1501b4835b..8da2a178cf85 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -575,6 +575,13 @@ Explicit Fencing Properties > .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c > :doc: explicit fencing properties > > + > +Variable Refresh Properties > +--- > + > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c > + :doc: Variable refresh properties > + > Existing KMS Properties > --- > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index f0deeb7298d0..2a12853ca917 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1254,6 +1254,28 @@ int drm_mode_create_scaling_mode_property(struct > drm_device *dev) > } > EXPORT_SYMBOL(drm_mode_create_scaling_mode_property); > > +/** > + * DOC: Variable refresh properties > + * > + * Variable refresh rate control is supported via properties on the > + * _connector and _crtc objects. > + * > + * "vrr_capable": > + * Optional _connector boolean property that drivers should attach > + * with drm_connector_attach_vrr_capable_property() on connectors that > + * could support variable refresh rates. Drivers should update the > + * property value by calling drm_connector_set_vrr_capable_property(). > + * > + * Absence of the property should indicate absence of support. > + * > + * "vrr_enabled": > + * Default _crtc boolean property that notifies the driver that the > + * variable refresh rate adjustment should be enabled for the CRTC. > + * > + * Support for variable refresh rate will depend on the "vrr_capable" > + * property exposed on the _connector object. We probably want to make it clear that this is a content hint. Maybe something like: * "vrr_enabled": * Default _crtc boolean property that notifies the driver that the * content on the CRTC is suitable for variable refresh presentation. * The driver will take that as a hint to enable variable refresh rate * if the receiver supports it, i.e. the "vrr_capable" property on the * _connector_object is true. Harry > + */ > + > /** > * drm_connector_attach_vrr_capable_property - creates the > * vrr_capable property > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> This patch introduces the 'vrr_enabled' CRTC property to allow
> dynamic control over variable refresh rate support for a CRTC.
>
> This property should be treated like a content hint to the driver -
> if the hardware or driver is not capable of driving variable refresh
> timings then this is not considered an error.
>
> Capability for variable refresh rate support should be determined
> by querying the vrr_capable drm connector property.
>
> It is worth noting that while the property is intended for atomic use
> it isn't filtered from legacy userspace queries. This allows for Xorg
> userspace drivers to implement support.
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_crtc.c| 2 ++
> drivers/gpu/drm/drm_mode_config.c | 6 ++
> include/drm/drm_crtc.h| 9 +
> include/drm/drm_mode_config.h | 5 +
> 5 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..eec396a57b88 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -433,6 +433,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
> drm_property_blob_put(mode);
> return ret;
> + } else if (property == config->prop_vrr_enabled) {
> + state->vrr_enabled = val;
> } else if (property == config->degamma_lut_property) {
> ret = drm_atomic_replace_property_blob_from_id(dev,
> >degamma_lut,
> @@ -491,6 +493,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = state->active;
> else if (property == config->prop_mode_id)
> *val = (state->mode_blob) ? state->mode_blob->base.id : 0;
> + else if (property == config->prop_vrr_enabled)
> + *val = state->vrr_enabled;
> else if (property == config->degamma_lut_property)
> *val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
> else if (property == config->ctm_property)
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5f488aa80bcd..e4eb2c897ff4 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -340,6 +340,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> struct drm_crtc *crtc,
> drm_object_attach_property(>base, config->prop_mode_id,
> 0);
> drm_object_attach_property(>base,
> config->prop_out_fence_ptr, 0);
> + drm_object_attach_property(>base,
> +config->prop_vrr_enabled, 0);
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index ee80788f2c40..5670c67f28d4 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -310,6 +310,12 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_mode_id = prop;
>
> + prop = drm_property_create_bool(dev, 0,
> + "VRR_ENABLED");
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_vrr_enabled = prop;
> +
> prop = drm_property_create(dev,
> DRM_MODE_PROP_BLOB,
> "DEGAMMA_LUT", 0);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b21437bc95bf..39c3900aab3c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -290,6 +290,15 @@ struct drm_crtc_state {
>*/
> u32 pageflip_flags;
>
> + /**
> + * @vrr_enabled:
> + *
> + * Indicates if variable refresh rate should be enabled for the CRTC.
> + * Support for the requested vrr state will depend on driver and
> + * hardware capabiltiy - lacking support is not treated as failure.
> + */
> + bool vrr_enabled;
> +
> /**
>* @event:
>*
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 928e4172a0bb..49f2fcfdb5fc 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -639,6 +639,11 @@ struct drm_mode_config {
>*
Re: [PATCH v5 1/4] drm: Add vrr_capable property to the drm connector
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces the "vrr_capable" property on the connector to
> allow userspace to query support for variable refresh rates.
>
> Atomic drivers should attach this property to connectors that are
> capable of driving variable refresh rates using
> drm_connector_attach_vrr_capable_property().
>
> The value should be updated based on driver and hardware capabiltiy
> by using drm_connector_set_vrr_capable_property().
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_connector.c | 49 +
> include/drm/drm_connector.h | 15 ++
> 2 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1e40e5decbe9..f0deeb7298d0 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1254,6 +1254,37 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev)
> }
> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>
> +/**
> + * drm_connector_attach_vrr_capable_property - creates the
> + * vrr_capable property
> + * @connector: connector to create the vrr_capable property on.
> + *
> + * This is used by atomic drivers to add support for querying
> + * variable refresh rate capability for a connector.
> + *
> + * Returns:
> + * Zero on success, negative errono on failure.
> + */
> +int drm_connector_attach_vrr_capable_property(
> + struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + if (!connector->vrr_capable_property) {
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE,
> + "vrr_capable");
> + if (!prop)
> + return -ENOMEM;
> +
> + connector->vrr_capable_property = prop;
> + drm_object_attach_property(>base, prop, 0);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_vrr_capable_property);
> +
> /**
> * drm_connector_attach_scaling_mode_property - attach atomic scaling mode
> property
> * @connector: connector to attach scaling mode property on.
> @@ -1582,6 +1613,24 @@ void drm_connector_set_link_status_property(struct
> drm_connector *connector,
> }
> EXPORT_SYMBOL(drm_connector_set_link_status_property);
>
> +/**
> + * drm_connector_set_vrr_capable_property - sets the variable refresh rate
> + * capable property for a connector
> + * @connector: drm connector
> + * @capable: True if the connector is variable refresh rate capable
> + *
> + * Should be used by atomic drivers to update the indicated support for
> + * variable refresh rate over a connector.
> + */
> +void drm_connector_set_vrr_capable_property(
> + struct drm_connector *connector, bool capable)
> +{
> + drm_object_property_set_value(>base,
> + connector->vrr_capable_property,
> + capable);
> +}
> +EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> +
> /**
> * drm_connector_init_panel_orientation_property -
> * initialize the connecters panel_orientation property
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 91a877fa00cb..b2263005234a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -910,6 +910,17 @@ struct drm_connector {
>*/
> struct drm_property *scaling_mode_property;
>
> + /**
> + * @vrr_capable_property: Optional property to help userspace
> + * query hardware support for variable refresh rate on a connector.
> + * connector. Drivers can add the property to a connector by
> + * calling drm_connector_attach_vrr_capable_property().
> + *
> + * This should be updated only by calling
> + * drm_connector_set_vrr_capable_property().
> + */
> + struct drm_property *vrr_capable_property;
> +
> /**
>* @content_protection_property: DRM ENUM property for content
>* protection. See drm_connector_attach_content_protection_property().
> @@ -1183,6 +1194,8 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev);
> int drm_connector_attach_content_type_property(struct drm_connector *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> u32 scaling_mod
Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support
On 2018-10-12 4:31 a.m., Koenig, Christian wrote: > Am 12.10.2018 um 10:26 schrieb Michel Dänzer: >> On 2018-10-11 9:44 p.m., Harry Wentland wrote: >>> On 2018-10-03 04:25 AM, Mike Lothian wrote: I'm curious to know whether this will/could work over PRIME >>> I don't see why this shouldn't work over PRIME as long as the >>> presenting GPU supports the new variable refresh rate API, but I know >>> very little about prime, so maybe someone else can chime in and give >>> a better opinion. >> It won't work for displays connected to a secondary GPU, because those >> aren't hooked up to the Present extension directly. >> >> It can theoretically work with render offloading, if the primary GPU can >> scan out directly from the shared pixmap. This is only possible with >> current AMD APUs which support scatter/gather scanout (Carrizo and >> newer?). > > Actually only Carizzo and Stoney at the moment because this is buggy on > Raven. Not sure if that is a pure software or a hardware problem. > > Christian. > >> One gotcha is that xf86-video-amdgpu currently doesn't allow >> flipping between buffers with different tiling parameters (BTW Harry, >> does that work with DC?), but that should be easy to fix. > Not currently. Fixable, but unfortunately not as easy as I'd hope. The good news is that I'm planning to rework that code so it would be easy to fix or should just happen on a per-flip basis. Harry ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2] drm: Get ref on CRTC commit object when waiting for flip_done
On 2018-10-18 1:38 p.m., Wentland, Harry wrote: > On 2018-10-16 11:48 a.m., Alex Deucher wrote: >> On Tue, Oct 16, 2018 at 11:00 AM Li, Sun peng (Leo) >> wrote: >>> >>> >>> >>> On 2018-10-16 08:33 AM, Daniel Vetter wrote: >>>> On Mon, Oct 15, 2018 at 09:46:40AM -0400, sunpeng...@amd.com wrote: >>>>> From: Leo Li >>>>> >>>>> This fixes a general protection fault, caused by accessing the contents >>>>> of a flip_done completion object that has already been freed. It occurs >>>>> due to the preemption of a non-blocking commit worker thread W by >>>>> another commit thread X. X continues to clear its atomic state at the >>>>> end, destroying the CRTC commit object that W still needs. Switching >>>>> back to W and accessing the commit objects then leads to bad results. >>>>> >>>>> Worker W becomes preemptable when waiting for flip_done to complete. At >>>>> this point, a frequently occurring commit thread X can take over. Here's >>>>> an example where W is a worker thread that flips on both CRTCs, and X >>>>> does a legacy cursor update on both CRTCs: >>>>> >>>>> ... >>>>> 1. W does flip work >>>>> 2. W runs commit_hw_done() >>>>> 3. W waits for flip_done on CRTC 1 >>>>> 4. > flip_done for CRTC 1 completes >>>>> 5. W finishes waiting for CRTC 1 >>>>> 6. W waits for flip_done on CRTC 2 >>>>> >>>>> 7. > Preempted by X >>>>> 8. > flip_done for CRTC 2 completes >>>>> 9. X atomic_check: hw_done and flip_done are complete on all CRTCs >>>>> 10. X updates cursor on both CRTCs >>>>> 11. X destroys atomic state >>>>> 12. X done >>>>> >>>>> 13. > Switch back to W >>>>> 14. W waits for flip_done on CRTC 2 >>>>> 15. W raises general protection fault >>>>> >>>>> The error looks like so: >>>>> >>>>> general protection fault: [#1] PREEMPT SMP PTI >>>>> **snip** >>>>> Call Trace: >>>>> lock_acquire+0xa2/0x1b0 >>>>> _raw_spin_lock_irq+0x39/0x70 >>>>> wait_for_completion_timeout+0x31/0x130 >>>>> drm_atomic_helper_wait_for_flip_done+0x64/0x90 [drm_kms_helper] >>>>> amdgpu_dm_atomic_commit_tail+0xcae/0xdd0 [amdgpu] >>>>> commit_tail+0x3d/0x70 [drm_kms_helper] >>>>> process_one_work+0x212/0x650 >>>>> worker_thread+0x49/0x420 >>>>> kthread+0xfb/0x130 >>>>> ret_from_fork+0x3a/0x50 >>>>> Modules linked in: x86_pkg_temp_thermal amdgpu(O) chash(O) >>>>> gpu_sched(O) drm_kms_helper(O) syscopyarea sysfillrect sysimgblt >>>>> fb_sys_fops ttm(O) drm(O) >>>>> >>>>> Note that i915 has this issue masked, since hw_done is signaled after >>>>> waiting for flip_done. Doing so will block the cursor update from >>>>> happening until hw_done is signaled, preventing the cursor commit from >>>>> destroying the state. >>>>> >>>>> v2: The reference on the commit object needs to be obtained before >>>>> hw_done() is signaled, since that's the point where another commit >>>>> is allowed to modify the state. Assuming that the >>>>> new_crtc_state->commit object still exists within flip_done() is >>>>> incorrect. >>>>> >>>>> Fix by getting a reference in setup_commit(), and releasing it >>>>> during default_clear(). >>>>> >>>>> Signed-off-by: Leo Li >>>>> --- >>>>> >>>>> Sending again, this time to the correct mailing list :) >>>>> >>>>> Leo >>>> >>>> Reviewed-by: Daniel Vetter >>>> Cc: sta...@vger.kernel.org >>>> >>>> I think it'd be really good if you could get intel-gfx-ci to test this >>>> patch. Simply submit it to intel-...@lists.freedesktop.org. I'll leave >>>> applying to one of the amd drm-misc committers, once it's passed CI. >> >> Leo, do you or Harry have drm-misc commit access yet? If no
Re: [PATCH v2] drm: Get ref on CRTC commit object when waiting for flip_done
On 2018-10-16 11:48 a.m., Alex Deucher wrote:
> On Tue, Oct 16, 2018 at 11:00 AM Li, Sun peng (Leo)
> wrote:
>>
>>
>>
>> On 2018-10-16 08:33 AM, Daniel Vetter wrote:
>>> On Mon, Oct 15, 2018 at 09:46:40AM -0400, sunpeng...@amd.com wrote:
From: Leo Li
This fixes a general protection fault, caused by accessing the contents
of a flip_done completion object that has already been freed. It occurs
due to the preemption of a non-blocking commit worker thread W by
another commit thread X. X continues to clear its atomic state at the
end, destroying the CRTC commit object that W still needs. Switching
back to W and accessing the commit objects then leads to bad results.
Worker W becomes preemptable when waiting for flip_done to complete. At
this point, a frequently occurring commit thread X can take over. Here's
an example where W is a worker thread that flips on both CRTCs, and X
does a legacy cursor update on both CRTCs:
...
1. W does flip work
2. W runs commit_hw_done()
3. W waits for flip_done on CRTC 1
4. > flip_done for CRTC 1 completes
5. W finishes waiting for CRTC 1
6. W waits for flip_done on CRTC 2
7. > Preempted by X
8. > flip_done for CRTC 2 completes
9. X atomic_check: hw_done and flip_done are complete on all CRTCs
10. X updates cursor on both CRTCs
11. X destroys atomic state
12. X done
13. > Switch back to W
14. W waits for flip_done on CRTC 2
15. W raises general protection fault
The error looks like so:
general protection fault: [#1] PREEMPT SMP PTI
**snip**
Call Trace:
lock_acquire+0xa2/0x1b0
_raw_spin_lock_irq+0x39/0x70
wait_for_completion_timeout+0x31/0x130
drm_atomic_helper_wait_for_flip_done+0x64/0x90 [drm_kms_helper]
amdgpu_dm_atomic_commit_tail+0xcae/0xdd0 [amdgpu]
commit_tail+0x3d/0x70 [drm_kms_helper]
process_one_work+0x212/0x650
worker_thread+0x49/0x420
kthread+0xfb/0x130
ret_from_fork+0x3a/0x50
Modules linked in: x86_pkg_temp_thermal amdgpu(O) chash(O)
gpu_sched(O) drm_kms_helper(O) syscopyarea sysfillrect sysimgblt
fb_sys_fops ttm(O) drm(O)
Note that i915 has this issue masked, since hw_done is signaled after
waiting for flip_done. Doing so will block the cursor update from
happening until hw_done is signaled, preventing the cursor commit from
destroying the state.
v2: The reference on the commit object needs to be obtained before
hw_done() is signaled, since that's the point where another commit
is allowed to modify the state. Assuming that the
new_crtc_state->commit object still exists within flip_done() is
incorrect.
Fix by getting a reference in setup_commit(), and releasing it
during default_clear().
Signed-off-by: Leo Li
---
Sending again, this time to the correct mailing list :)
Leo
>>>
>>> Reviewed-by: Daniel Vetter
>>> Cc: sta...@vger.kernel.org
>>>
>>> I think it'd be really good if you could get intel-gfx-ci to test this
>>> patch. Simply submit it to intel-...@lists.freedesktop.org. I'll leave
>>> applying to one of the amd drm-misc committers, once it's passed CI.
>
> Leo, do you or Harry have drm-misc commit access yet? If not, you should.
>
I believe I do and will push the patch. Leo's getting the ball rolling to get
access (fdo account, etc).
Harry
> Alex
>
>>>
>>> Cheers, Daniel
>>
>> Thanks for the rb!
>>
>> On the topic of CI, is it possible to write a test (maybe one already
>> exists) for this issue? I've attempted to do one here:
>>
>> https://patchwork.freedesktop.org/patch/256319/
>>
>> The problem is finding a surefire way to trigger the sequence, I'm not
>> sure how that can be done. If you have any ideas, I would love to hear them.
>>
>> Leo
>>
>>>
drivers/gpu/drm/drm_atomic.c| 5 +
drivers/gpu/drm/drm_atomic_helper.c | 12
include/drm/drm_atomic.h| 11 +++
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e..12ae917 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -174,6 +174,11 @@ void drm_atomic_state_default_clear(struct
drm_atomic_state *state)
state->crtcs[i].state = NULL;
state->crtcs[i].old_state = NULL;
state->crtcs[i].new_state = NULL;
+
+if (state->crtcs[i].commit) {
+drm_crtc_commit_put(state->crtcs[i].commit);
+
Re: [PATCH] powerplay: Respect units on max dcfclk watermark
On 2018-10-18 11:30 a.m., David Francis wrote: > In a refactor, the watermark clock inputs to > powerplay from DC were changed from units of 10kHz to > kHz clocks. > > One division by 100 was not converted into a division > by 1000. > > Signed-off-by: David Francis Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c > b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c > index 4714b5b59825..99a33c33a32c 100644 > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c > @@ -718,7 +718,7 @@ int smu_set_watermarks_for_clocks_ranges(void *wt_table, > table->WatermarkRow[1][i].MaxClock = > cpu_to_le16((uint16_t) > > (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_dcfclk_clk_in_khz) / > - 100); > + 1000); > table->WatermarkRow[1][i].MinUclk = > cpu_to_le16((uint16_t) > > (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_mem_clk_in_khz) / > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 04/10] drm/amd/display: dc/bios: add support for DCE6
On 2018-10-17 4:42 p.m., Alex Deucher wrote:
> On Wed, Oct 17, 2018 at 4:16 PM Wentland, Harry
> wrote:
>>
>> On 2018-10-17 4:10 p.m., Alex Deucher wrote:
>>> On Wed, Oct 17, 2018 at 3:54 PM Wentland, Harry
>>> wrote:
>>>>
>>>> On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
>>>>> DCE6 targets are added replicating existing DCE8 implementation.
>>>>> ---
>>>>> drivers/gpu/drm/amd/display/dc/bios/Makefile | 9 +
>>>>> .../display/dc/bios/command_table_helper.c| 8 +
>>>>> .../display/dc/bios/command_table_helper.h| 3 +
>>>>> .../display/dc/bios/command_table_helper2.c | 8 +
>>>>> .../display/dc/bios/command_table_helper2.h | 3 +
>>>>> .../bios/dce60/command_table_helper_dce60.c | 354 ++
>>>>> .../bios/dce60/command_table_helper_dce60.h | 33 ++
>>>>> 7 files changed, 418 insertions(+)
>>>>> create mode 100644
>>>>> drivers/gpu/drm/amd/display/dc/bios/dce60/command_table_helper_dce60.c
>>>>> create mode 100644
>>>>> drivers/gpu/drm/amd/display/dc/bios/dce60/command_table_helper_dce60.h
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/display/dc/bios/Makefile
>>>>> b/drivers/gpu/drm/amd/display/dc/bios/Makefile
>>>>> index 239e86bbec5a..ed6b5e9763f6 100644
>>>>> --- a/drivers/gpu/drm/amd/display/dc/bios/Makefile
>>>>> +++ b/drivers/gpu/drm/amd/display/dc/bios/Makefile
>>>>> @@ -31,6 +31,15 @@ AMD_DAL_BIOS = $(addprefix
>>>>> $(AMDDALPATH)/dc/bios/,$(BIOS))
>>>>>
>>>>> AMD_DISPLAY_FILES += $(AMD_DAL_BIOS)
>>>>>
>>>>> +###
>>>>> +# DCE 6x
>>>>> +###
>>>>> +# All DCE6.x are derived from DCE6.0, so 6.0 MUST be defined if ANY of
>>>>> +# DCE6.x is compiled.
>>>>> +ifdef CONFIG_DRM_AMD_DC_SI
>>>>> +AMD_DISPLAY_FILES +=
>>>>> $(AMDDALPATH)/dc/bios/dce60/command_table_helper_dce60.o
>>>>> +endif
>>>>> +
>>>>>
>>>>> ###
>>>>> # DCE 8x
>>>>>
>>>>> ###
>>>>> diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
>>>>> b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
>>>>> index 253bbb1eea60..48b4ef03fc8f 100644
>>>>> --- a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
>>>>> +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
>>>>> @@ -36,6 +36,14 @@ bool dal_bios_parser_init_cmd_tbl_helper(
>>>>> enum dce_version dce)
>>>>> {
>>>>> switch (dce) {
>>>>> +#if defined(CONFIG_DRM_AMD_DC_SI)
>>>>> + case DCE_VERSION_6_0:
>>>>> + case DCE_VERSION_6_1:
>>>>> + case DCE_VERSION_6_4:
>>>>> + *h = dal_cmd_tbl_helper_dce60_get_table();
>>>>
>>>> Can we just point these to the dce80 version since they're exactly the
>>>> same?
>>>
>>> Some of the dig transmitter and encoder cmd tables had different
>>> versions on DCE6 vs 8. I'm not sure if we need to do any different
>>> translations for some of these.
>>>
>>
>> Currently it's an exact copy. Since you remember differences it makes sense
>> to duplicate this for DCE6 so we can update it for any difference if we'll
>> need that.
>>
>> Mauro, ignore my comments in this case. :)
>
> I just double checked the vbios DCE8 design documents and the cmd
> tables are compatible (the only major difference was the addition of
> the 7th phy which won't show up on DCE6, so not an issue). I also
> double check the cmd table versions on a few bioses and they are the
> same. We should be fine with just sharing the DCE8 code for DCE6 as
> well. Sorry for the noise.
>
Thanks for looking into the design docs. Looks like we're good to share this
code then.
Harry
> Alex
>
>>
>> Harry
>>
>>> Alex
>>>
>>>>
>>>>> + return true;
>>>>> +#endif
>>
Re: [PATCH v2 07/10] drm/amd/display: dc/irq: add support for DCE6
On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
> DCE6 targets are added replicating existing DCE8 implementation.
>
> NOTE: due to missing CRTC_VERTICAL_INTERRUPT0_CONTROL registers/masks,
> dce/dce_8_0_{d,sh_mask}.h headers were used instead of
> dce/dce_6_0_{d,sh_mask}.h
> but only as exception in dce/irq_service_dce60.c
>
> IMPORTANT: Coding of dce/irq_service_dce60.c requires review to understand
> if dce_6_0_{d,sh_mask}.h should be updated with macros/registers/masks
> ---
> drivers/gpu/drm/amd/display/dc/irq/Makefile | 11 +
> .../display/dc/irq/dce60/irq_service_dce60.c | 303 ++
> .../display/dc/irq/dce60/irq_service_dce60.h | 35 ++
> .../gpu/drm/amd/display/dc/irq/irq_service.c | 3 +
> 4 files changed, 352 insertions(+)
> create mode 100644
> drivers/gpu/drm/amd/display/dc/irq/dce60/irq_service_dce60.c
> create mode 100644
> drivers/gpu/drm/amd/display/dc/irq/dce60/irq_service_dce60.h
>
> diff --git a/drivers/gpu/drm/amd/display/dc/irq/Makefile
> b/drivers/gpu/drm/amd/display/dc/irq/Makefile
> index 498515aad4a5..e38b6d8d614d 100644
> --- a/drivers/gpu/drm/amd/display/dc/irq/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/irq/Makefile
> @@ -30,6 +30,17 @@ AMD_DAL_IRQ = $(addprefix $(AMDDALPATH)/dc/irq/,$(IRQ))
>
> AMD_DISPLAY_FILES += $(AMD_DAL_IRQ)
>
> +###
> +# DCE 6x
> +###
> +ifdef CONFIG_DRM_AMD_DC_SI
> +IRQ_DCE60 = irq_service_dce60.o
> +
> +AMD_DAL_IRQ_DCE60 = $(addprefix $(AMDDALPATH)/dc/irq/dce60/,$(IRQ_DCE60))
> +
> +AMD_DISPLAY_FILES += $(AMD_DAL_IRQ_DCE60)
> +endif
> +
>
> ###
> # DCE 8x
>
> ###
> diff --git a/drivers/gpu/drm/amd/display/dc/irq/dce60/irq_service_dce60.c
> b/drivers/gpu/drm/amd/display/dc/irq/dce60/irq_service_dce60.c
> new file mode 100644
> index ..107e0dcb5f80
> --- /dev/null
> +++ b/drivers/gpu/drm/amd/display/dc/irq/dce60/irq_service_dce60.c
> @@ -0,0 +1,303 @@
> +/*
> + * Copyright 2012-15 Advanced Micro Devices, Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: AMD
> + *
> + */
> +
> +#include "dm_services.h"
> +
> +#include "include/logger_interface.h"
> +
> +#include "irq_service_dce60.h"
> +#include "../dce110/irq_service_dce110.h"
> +
> +#include "dce/dce_8_0_d.h"
> +#include "dce/dce_8_0_sh_mask.h"
> +
> +#include "ivsrcid/ivsrcid_vislands30.h"
> +
> +#include "dc_types.h"
> +
> +static bool hpd_ack(
> + struct irq_service *irq_service,
> + const struct irq_source_info *info)
> +{
> + uint32_t addr = info->status_reg;
> + uint32_t value = dm_read_reg(irq_service->ctx, addr);
> + uint32_t current_status =
> + get_reg_field_value(
> + value,
> + DC_HPD1_INT_STATUS,
> + DC_HPD1_SENSE_DELAYED);
> +
> + dal_irq_service_ack_generic(irq_service, info);
> +
> + value = dm_read_reg(irq_service->ctx, info->enable_reg);
> +
> + set_reg_field_value(
> + value,
> + current_status ? 0 : 1,
> + DC_HPD1_INT_CONTROL,
> + DC_HPD1_INT_POLARITY);
> +
> + dm_write_reg(irq_service->ctx, info->enable_reg, value);
> +
> + return true;
> +}
> +
> +static const struct irq_source_info_funcs hpd_irq_info_funcs = {
> + .set = NULL,
> + .ack = hpd_ack
> +};
> +
> +static const struct irq_source_info_funcs hpd_rx_irq_info_funcs = {
> + .set = NULL,
> + .ack = NULL
> +};
> +
> +static const struct irq_source_info_funcs pflip_irq_info_funcs = {
> + .set = NULL,
> + .ack = NULL
> +};
> +
> +static const struct irq_source_info_funcs vblank_irq_info_funcs = {
> +
Re: [PATCH v2 03/10] drm/amd/display: dc/core: add DCE6 support
On 2018-10-17 3:50 p.m., Wentland, Harry wrote:
> On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
>> DCE6 targets are added as branching of existing DCE8 implementation.
>
> All your parents require a Signed-off-by. See
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
s/parents/patches
Harry
>
> Harry
>
>> ---
>> .../gpu/drm/amd/display/dc/core/dc_resource.c | 29 +++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>> index a5eb80aa3dd9..07bd4f72acc5 100644
>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>> @@ -37,6 +37,9 @@
>> #include "virtual/virtual_stream_encoder.h"
>> #include "dpcd_defs.h"
>>
>> +#if defined(CONFIG_DRM_AMD_DC_SI)
>> +#include "dce60/dce60_resource.h"
>> +#endif
>> #include "dce80/dce80_resource.h"
>> #include "dce100/dce100_resource.h"
>> #include "dce110/dce110_resource.h"
>> @@ -53,6 +56,18 @@ enum dce_version resource_parse_asic_id(struct hw_asic_id
>> asic_id)
>> enum dce_version dc_version = DCE_VERSION_UNKNOWN;
>> switch (asic_id.chip_family) {
>>
>> +#if defined(CONFIG_DRM_AMD_DC_SI)
>> +case FAMILY_SI:
>> +if (ASIC_REV_IS_TAHITI_P(asic_id.hw_internal_rev) ||
>> +ASIC_REV_IS_PITCAIRN_PM(asic_id.hw_internal_rev) ||
>> +ASIC_REV_IS_CAPEVERDE_M(asic_id.hw_internal_rev))
>> +dc_version = DCE_VERSION_6_0;
>> +else if (ASIC_REV_IS_OLAND_M(asic_id.hw_internal_rev))
>> +dc_version = DCE_VERSION_6_4;
>> +else
>> +dc_version = DCE_VERSION_6_1;
>> +break;
>> +#endif
>> case FAMILY_CI:
>> dc_version = DCE_VERSION_8_0;
>> break;
>> @@ -110,6 +125,20 @@ struct resource_pool *dc_create_resource_pool(
>> struct resource_pool *res_pool = NULL;
>>
>> switch (dc_version) {
>> +#if defined(CONFIG_DRM_AMD_DC_SI)
>> +case DCE_VERSION_6_0:
>> +res_pool = dce60_create_resource_pool(
>> +num_virtual_links, dc);
>> +break;
>> +case DCE_VERSION_6_1:
>> +res_pool = dce61_create_resource_pool(
>> +num_virtual_links, dc);
>> +break;
>> +case DCE_VERSION_6_4:
>> +res_pool = dce64_create_resource_pool(
>> +num_virtual_links, dc);
>> +break;
>> +#endif
>> case DCE_VERSION_8_0:
>> res_pool = dce80_create_resource_pool(
>> num_virtual_links, dc);
>>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 04/10] drm/amd/display: dc/bios: add support for DCE6
On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
> DCE6 targets are added replicating existing DCE8 implementation.
> ---
> drivers/gpu/drm/amd/display/dc/bios/Makefile | 9 +
> .../display/dc/bios/command_table_helper.c| 8 +
> .../display/dc/bios/command_table_helper.h| 3 +
> .../display/dc/bios/command_table_helper2.c | 8 +
> .../display/dc/bios/command_table_helper2.h | 3 +
> .../bios/dce60/command_table_helper_dce60.c | 354 ++
> .../bios/dce60/command_table_helper_dce60.h | 33 ++
> 7 files changed, 418 insertions(+)
> create mode 100644
> drivers/gpu/drm/amd/display/dc/bios/dce60/command_table_helper_dce60.c
> create mode 100644
> drivers/gpu/drm/amd/display/dc/bios/dce60/command_table_helper_dce60.h
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/Makefile
> b/drivers/gpu/drm/amd/display/dc/bios/Makefile
> index 239e86bbec5a..ed6b5e9763f6 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/bios/Makefile
> @@ -31,6 +31,15 @@ AMD_DAL_BIOS = $(addprefix $(AMDDALPATH)/dc/bios/,$(BIOS))
>
> AMD_DISPLAY_FILES += $(AMD_DAL_BIOS)
>
> +###
> +# DCE 6x
> +###
> +# All DCE6.x are derived from DCE6.0, so 6.0 MUST be defined if ANY of
> +# DCE6.x is compiled.
> +ifdef CONFIG_DRM_AMD_DC_SI
> +AMD_DISPLAY_FILES += $(AMDDALPATH)/dc/bios/dce60/command_table_helper_dce60.o
> +endif
> +
>
> ###
> # DCE 8x
>
> ###
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
> b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
> index 253bbb1eea60..48b4ef03fc8f 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
> @@ -36,6 +36,14 @@ bool dal_bios_parser_init_cmd_tbl_helper(
> enum dce_version dce)
> {
> switch (dce) {
> +#if defined(CONFIG_DRM_AMD_DC_SI)
> + case DCE_VERSION_6_0:
> + case DCE_VERSION_6_1:
> + case DCE_VERSION_6_4:
> + *h = dal_cmd_tbl_helper_dce60_get_table();
Can we just point these to the dce80 version since they're exactly the same?
> + return true;
> +#endif
> +
> case DCE_VERSION_8_0:
> case DCE_VERSION_8_1:
> case DCE_VERSION_8_3:
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.h
> b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.h
> index 4c3789df253d..dfd30aaf4032 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.h
> +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.h
> @@ -26,6 +26,9 @@
> #ifndef __DAL_COMMAND_TABLE_HELPER_H__
> #define __DAL_COMMAND_TABLE_HELPER_H__
>
> +#if defined(CONFIG_DRM_AMD_DC_SI)
> +#include "dce60/command_table_helper_dce60.h"
> +#endif
> #include "dce80/command_table_helper_dce80.h"
> #include "dce110/command_table_helper_dce110.h"
> #include "dce112/command_table_helper_dce112.h"
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.c
> b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.c
> index 65b006ad372e..92288c582934 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.c
> @@ -37,6 +37,14 @@ bool dal_bios_parser_init_cmd_tbl_helper2(
> enum dce_version dce)
> {
> switch (dce) {
> +#if defined(CONFIG_DRM_AMD_DC_SI)
> + case DCE_VERSION_6_0:
> + case DCE_VERSION_6_1:
> + case DCE_VERSION_6_4:
> + *h = dal_cmd_tbl_helper_dce60_get_table();
Same as above.
Harry
> + return true;
> +#endif
> +
> case DCE_VERSION_8_0:
> case DCE_VERSION_8_1:
> case DCE_VERSION_8_3:
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.h
> b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.h
> index 785fcb20a1b9..66e0a3e73768 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.h
> +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.h
> @@ -26,6 +26,9 @@
> #ifndef __DAL_COMMAND_TABLE_HELPER2_H__
> #define __DAL_COMMAND_TABLE_HELPER2_H__
>
> +#if defined(CONFIG_DRM_AMD_DC_SI)
> +#include "dce60/command_table_helper_dce60.h"
> +#endif
> #include "dce80/command_table_helper_dce80.h"
> #include "dce110/command_table_helper_dce110.h"
> #include "dce112/command_table_helper2_dce112.h"
> diff --git
> a/drivers/gpu/drm/amd/display/dc/bios/dce60/command_table_helper_dce60.c
> b/drivers/gpu/drm/amd/display/dc/bios/dce60/command_table_helper_dce60.c
> new file mode 100644
> index ..552778ce9835
> --- /dev/null
> +++
Re: [PATCH v2 03/10] drm/amd/display: dc/core: add DCE6 support
On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
> DCE6 targets are added as branching of existing DCE8 implementation.
All your parents require a Signed-off-by. See
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
Harry
> ---
> .../gpu/drm/amd/display/dc/core/dc_resource.c | 29 +++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> index a5eb80aa3dd9..07bd4f72acc5 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> @@ -37,6 +37,9 @@
> #include "virtual/virtual_stream_encoder.h"
> #include "dpcd_defs.h"
>
> +#if defined(CONFIG_DRM_AMD_DC_SI)
> +#include "dce60/dce60_resource.h"
> +#endif
> #include "dce80/dce80_resource.h"
> #include "dce100/dce100_resource.h"
> #include "dce110/dce110_resource.h"
> @@ -53,6 +56,18 @@ enum dce_version resource_parse_asic_id(struct hw_asic_id
> asic_id)
> enum dce_version dc_version = DCE_VERSION_UNKNOWN;
> switch (asic_id.chip_family) {
>
> +#if defined(CONFIG_DRM_AMD_DC_SI)
> + case FAMILY_SI:
> + if (ASIC_REV_IS_TAHITI_P(asic_id.hw_internal_rev) ||
> + ASIC_REV_IS_PITCAIRN_PM(asic_id.hw_internal_rev) ||
> + ASIC_REV_IS_CAPEVERDE_M(asic_id.hw_internal_rev))
> + dc_version = DCE_VERSION_6_0;
> + else if (ASIC_REV_IS_OLAND_M(asic_id.hw_internal_rev))
> + dc_version = DCE_VERSION_6_4;
> + else
> + dc_version = DCE_VERSION_6_1;
> + break;
> +#endif
> case FAMILY_CI:
> dc_version = DCE_VERSION_8_0;
> break;
> @@ -110,6 +125,20 @@ struct resource_pool *dc_create_resource_pool(
> struct resource_pool *res_pool = NULL;
>
> switch (dc_version) {
> +#if defined(CONFIG_DRM_AMD_DC_SI)
> + case DCE_VERSION_6_0:
> + res_pool = dce60_create_resource_pool(
> + num_virtual_links, dc);
> + break;
> + case DCE_VERSION_6_1:
> + res_pool = dce61_create_resource_pool(
> + num_virtual_links, dc);
> + break;
> + case DCE_VERSION_6_4:
> + res_pool = dce64_create_resource_pool(
> + num_virtual_links, dc);
> + break;
> +#endif
> case DCE_VERSION_8_0:
> res_pool = dce80_create_resource_pool(
> num_virtual_links, dc);
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 02/10] drm/amd/display: dc/dce: add DCE6 support (v2)
On 2018-10-17 4:35 a.m., Mauro Rossi wrote:
> DCE6 targets are added replicating existing DCE8 implementation.
>
> NOTE: dce_8_0_{d,sh_mask}.h headers used instead of dce_6_0_{d,sh_mask}.h
> only to build dce60_resource.c due to missing *_DCE60 macros/registers/masks
>
> IMPORTANT: Coding of dce60_resource.c requires review to understand
> if dce_6_0_{d,sh_mask}.h should be updated with macros/registers/masks
>
> (v2) updated dce60_{hw_sequencer,resources}.c as per amd-staging-drm-next
> removed dce_version cases in dc/dce/dce_clock_source.c
> ---
> drivers/gpu/drm/amd/display/dc/Makefile |4 +
> drivers/gpu/drm/amd/display/dc/dce60/Makefile | 34 +
> .../amd/display/dc/dce60/dce60_hw_sequencer.c | 82 +
> .../amd/display/dc/dce60/dce60_hw_sequencer.h | 36 +
> .../drm/amd/display/dc/dce60/dce60_resource.c | 1458 +
> .../drm/amd/display/dc/dce60/dce60_resource.h | 47 +
> .../display/dc/dce60/dce60_timing_generator.c | 242 +++
> .../display/dc/dce60/dce60_timing_generator.h | 39 +
> .../include/asic_reg/dce/dce_6_0_sh_mask.h|4 +
> 9 files changed, 1946 insertions(+)
> create mode 100644 drivers/gpu/drm/amd/display/dc/dce60/Makefile
> create mode 100644 drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.c
> create mode 100644 drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.h
> create mode 100644 drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.c
> create mode 100644 drivers/gpu/drm/amd/display/dc/dce60/dce60_resource.h
> create mode 100644
> drivers/gpu/drm/amd/display/dc/dce60/dce60_timing_generator.c
> create mode 100644
> drivers/gpu/drm/amd/display/dc/dce60/dce60_timing_generator.h
>
> diff --git a/drivers/gpu/drm/amd/display/dc/Makefile
> b/drivers/gpu/drm/amd/display/dc/Makefile
> index aed538a4d1ba..d5d5acd57559 100644
> --- a/drivers/gpu/drm/amd/display/dc/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/Makefile
> @@ -36,6 +36,10 @@ DC_LIBS += dce110
> DC_LIBS += dce100
> DC_LIBS += dce80
>
> +ifdef CONFIG_DRM_AMD_DC_SI
> +DC_LIBS += dce60
> +endif
> +
> AMD_DC = $(addsuffix /Makefile, $(addprefix
> $(FULL_AMD_DISPLAY_PATH)/dc/,$(DC_LIBS)))
>
> include $(AMD_DC)
> diff --git a/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> new file mode 100644
> index ..39afd7c59a7c
> --- /dev/null
> +++ b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
> @@ -0,0 +1,34 @@
> +#
> +# Copyright 2017 Advanced Micro Devices, Inc.
> +#
> +# Permission is hereby granted, free of charge, to any person obtaining a
> +# copy of this software and associated documentation files (the "Software"),
> +# to deal in the Software without restriction, including without limitation
> +# the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +# and/or sell copies of the Software, and to permit persons to whom the
> +# Software is furnished to do so, subject to the following conditions:
> +#
> +# The above copyright notice and this permission notice shall be included in
> +# all copies or substantial portions of the Software.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> +# THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> +# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> +# OTHER DEALINGS IN THE SOFTWARE.
> +#
> +#
> +# Makefile for the 'controller' sub-component of DAL.
> +# It provides the control and status of HW CRTC block.
> +
> +DCE60 = dce60_timing_generator.o dce60_hw_sequencer.o \
> + dce60_resource.o
> +
> +AMD_DAL_DCE60 = $(addprefix $(AMDDALPATH)/dc/dce60/,$(DCE60))
> +
> +AMD_DISPLAY_FILES += $(AMD_DAL_DCE60)
> +
> +
> +
> diff --git a/drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.c
> b/drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.c
> new file mode 100644
> index ..502172bf6097
> --- /dev/null
> +++ b/drivers/gpu/drm/amd/display/dc/dce60/dce60_hw_sequencer.c
> @@ -0,0 +1,82 @@
> +/*
> + * Copyright 2015 Advanced Micro Devices, Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT
