date:20190426

[PATCH AUTOSEL 4.19 30/53] drm/amd/display: fix cursor black issue

2019-04-26 Thread Sasha Levin

From: tiancyin 

[ Upstream commit c1cefe115d1cdc460014483319d440b2f0d07c68 ]

[Why]
the member sdr_white_level of struct dc_cursor_attributes was not
initialized, then the random value result that
dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal
value is 0x3c00), this cause the black cursor issue.

[how]
just initilize the obj of struct dc_cursor_attributes to zero to avoid
the random value.

Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Tianci Yin 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 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 2b8b892eb846..76ee2de43ea6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4028,6 +4028,7 @@ static void handle_cursor_update(struct drm_plane *plane,
amdgpu_crtc->cursor_width = plane->state->crtc_w;
amdgpu_crtc->cursor_height = plane->state->crtc_h;
 
+   memset(, 0, sizeof(attributes));
attributes.address.high_part = upper_32_bits(address);
attributes.address.low_part  = lower_32_bits(address);
attributes.width = plane->state->crtc_w;
-- 
2.19.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH AUTOSEL 4.19 29/53] drm/amdkfd: Add picasso pci id

2019-04-26 Thread Sasha Levin

From: Alex Deucher 

[ Upstream commit e7ad88553aa1d48e950ca9a4934d246c1bee4be4 ]

Picasso is a new raven variant.

Reviewed-by: Kent Russell 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 5aba50f63ac6..06d19bb89cfc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -275,6 +275,7 @@ static const struct kfd_deviceid supported_devices[] = {
{ 0x9876, _device_info },   /* Carrizo */
{ 0x9877, _device_info },   /* Carrizo */
{ 0x15DD, _device_info }, /* Raven */
+   { 0x15D8, _device_info }, /* Raven */
 #endif
{ 0x67A0, _device_info },/* Hawaii */
{ 0x67A1, _device_info },/* Hawaii */
-- 
2.19.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH AUTOSEL 5.0 40/79] drm/amdgpu: amdgpu_device_recover_vram always failed if only one node in shadow_list

2019-04-26 Thread Sasha Levin

From: wentalou 

[ Upstream commit 1712fb1a2f6829150032ac76eb0e39b82a549cfb ]

amdgpu_bo_restore_shadow would assign zero to r if succeeded.
r would remain zero if there is only one node in shadow_list.
current code would always return failure when r <= 0.
restart the timeout for each wait was a rather problematic bug as well.
The value of tmo SHOULD be changed, otherwise we wait tmo jiffies on each loop.

Signed-off-by: Wentao Lou 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 7ff3a28fc903..d55dd570a702 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3158,11 +3158,16 @@ static int amdgpu_device_recover_vram(struct 
amdgpu_device *adev)
break;
 
if (fence) {
-   r = dma_fence_wait_timeout(fence, false, tmo);
+   tmo = dma_fence_wait_timeout(fence, false, tmo);
dma_fence_put(fence);
fence = next;
-   if (r <= 0)
+   if (tmo == 0) {
+   r = -ETIMEDOUT;
break;
+   } else if (tmo < 0) {
+   r = tmo;
+   break;
+   }
} else {
fence = next;
}
@@ -3173,8 +3178,8 @@ static int amdgpu_device_recover_vram(struct 
amdgpu_device *adev)
tmo = dma_fence_wait_timeout(fence, false, tmo);
dma_fence_put(fence);
 
-   if (r <= 0 || tmo <= 0) {
-   DRM_ERROR("recover vram bo from shadow failed\n");
+   if (r < 0 || tmo <= 0) {
+   DRM_ERROR("recover vram bo from shadow failed, r is %ld, tmo is 
%ld\n", r, tmo);
return -EIO;
}
 
-- 
2.19.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH AUTOSEL 5.0 39/79] drm/amdgpu: Adjust IB test timeout for XGMI configuration

2019-04-26 Thread Sasha Levin

From: shaoyunl 

[ Upstream commit d4162c61e253177936fcfe6c29f7b224d9a1efb8 ]

On XGMI configuration the ib test may take longer to finish

Signed-off-by: shaoyunl 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index c48207b377bc..b82c5fca217b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -35,6 +35,7 @@
 #include "amdgpu_trace.h"
 
 #define AMDGPU_IB_TEST_TIMEOUT msecs_to_jiffies(1000)
+#define AMDGPU_IB_TEST_GFX_XGMI_TIMEOUTmsecs_to_jiffies(2000)
 
 /*
  * IB
@@ -344,6 +345,8 @@ int amdgpu_ib_ring_tests(struct amdgpu_device *adev)
 * cost waiting for it coming back under RUNTIME only
*/
tmo_gfx = 8 * AMDGPU_IB_TEST_TIMEOUT;
+   } else if (adev->gmc.xgmi.hive_id) {
+   tmo_gfx = AMDGPU_IB_TEST_GFX_XGMI_TIMEOUT;
}
 
for (i = 0; i < adev->num_rings; ++i) {
-- 
2.19.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH AUTOSEL 5.0 41/79] drm/amd/display: fix cursor black issue

2019-04-26 Thread Sasha Levin

From: tiancyin 

[ Upstream commit c1cefe115d1cdc460014483319d440b2f0d07c68 ]

[Why]
the member sdr_white_level of struct dc_cursor_attributes was not
initialized, then the random value result that
dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal
value is 0x3c00), this cause the black cursor issue.

[how]
just initilize the obj of struct dc_cursor_attributes to zero to avoid
the random value.

Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Tianci Yin 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 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 83c8a0407537..84ee77786944 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4455,6 +4455,7 @@ static void handle_cursor_update(struct drm_plane *plane,
amdgpu_crtc->cursor_width = plane->state->crtc_w;
amdgpu_crtc->cursor_height = plane->state->crtc_h;
 
+   memset(, 0, sizeof(attributes));
attributes.address.high_part = upper_32_bits(address);
attributes.address.low_part  = lower_32_bits(address);
attributes.width = plane->state->crtc_w;
-- 
2.19.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH AUTOSEL 5.0 38/79] drm/amdkfd: Add picasso pci id

2019-04-26 Thread Sasha Levin

From: Alex Deucher 

[ Upstream commit e7ad88553aa1d48e950ca9a4934d246c1bee4be4 ]

Picasso is a new raven variant.

Reviewed-by: Kent Russell 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 8be9677c0c07..cf9a49f49d3a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -320,6 +320,7 @@ static const struct kfd_deviceid supported_devices[] = {
{ 0x9876, _device_info },   /* Carrizo */
{ 0x9877, _device_info },   /* Carrizo */
{ 0x15DD, _device_info }, /* Raven */
+   { 0x15D8, _device_info }, /* Raven */
 #endif
{ 0x67A0, _device_info },/* Hawaii */
{ 0x67A1, _device_info },/* Hawaii */
-- 
2.19.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v2)

2019-04-26 Thread Mario Kleiner

On Fri, Apr 26, 2019 at 7:12 PM Kazlauskas, Nicholas
 wrote:
>
> On 4/26/19 6:50 AM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some testing on DCE-8
> > and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
> > programming with a lag of one frame, so the special BTR hw
> > programming for intermediate fixed duration frames must be
> > done inside the current frame at flip submission in atomic
> > commit tail, ie. one vblank earlier, and the fixed refresh
> > intermediate frame mode must be also terminated one vblank
> > earlier on pre-DCE12 display engines.
> >
> > To achieve proper termination on < DCE-12 shift the point
> > when the switch-back from fixed vblank duration to variable
> > vblank duration happens from the start of VBLANK (vblank irq,
> > as done on DCE-12+) to back-porch or end of VBLANK (handled
> > by vupdate irq handler). We must leave the switch-back code
> > inside VBLANK irq for DCE12+, as before.
> >
> > Doing this, we get much better behaviour of BTR for up-sweeps,
> > ie. going from short to long frame durations (~high to low fps)
> > and for constant framerate flips, as tested on DCE-8 and
> > DCE-11. Behaviour is still not quite as good as on DCN-1
> > though.
> >
> > On down-sweeps, going from long to short frame durations
> > (low fps to high fps) < DCE-12 is a little bit improved,
> > although by far not as much as for up-sweeps and constant
> > fps.
> >
> > v2: Fix some wrong locking, as pointed out by Nicholas.
> > Signed-off-by: Mario Kleiner 
>
> Still looks good to me, but I just noticed one other minor nitpick (sorry!)
>
> > ---
> >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 45 +--
> >   1 file changed, 42 insertions(+), 3 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 76b6e621793f..7241e1f3ebec 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -364,6 +364,7 @@ static void dm_vupdate_high_irq(void *interrupt_params)
> >   struct amdgpu_device *adev = irq_params->adev;
> >   struct amdgpu_crtc *acrtc;
> >   struct dm_crtc_state *acrtc_state;
> > + unsigned long flags;
> >
> >   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> > IRQ_TYPE_VUPDATE);
> >
> > @@ -381,6 +382,22 @@ static void dm_vupdate_high_irq(void *interrupt_params)
> >*/
> >   if (amdgpu_dm_vrr_active(acrtc_state))
> >   drm_crtc_handle_vblank(>base);
>
> Can't this block be merged with the one below?
>
> With the condition also changed to just:
>
> if (acrtc_state->stream && adev->family < AMDGPU_FAMILY_AI)
> ...

Done. New series out, retested.
-mario

>
> I also noticed that the crtc_state itself is always accessed unlocked
> for checking whether VRR is on/off which is probably a bug... but this
> patch shouldn't be the one to fix that. At the very least though it can
> leave things in a bit better shape like you've already done. Thanks!
>
> Nicholas Kazlauskas
>
> > +
> > + if (acrtc_state->stream && adev->family < AMDGPU_FAMILY_AI &&
> > + acrtc_state->vrr_params.supported &&
> > + acrtc_state->freesync_config.state == 
> > VRR_STATE_ACTIVE_VARIABLE) {
> > + spin_lock_irqsave(>ddev->event_lock, flags);
> > + 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);
> > + spin_unlock_irqrestore(>ddev->event_lock, 
> > flags);
> > + }
> >   }
> >   }
> >
> > @@ -390,6 +407,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
> >   struct amdgpu_device *adev = irq_params->adev;
> >   struct amdgpu_crtc *acrtc;
> >   struct dm_crtc_state *acrtc_state;
> > + unsigned long flags;
> >
> >   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> > IRQ_TYPE_VBLANK);
> >
> > @@ -412,9 +430,10 @@ static void dm_crtc_high_irq(void *interrupt_params)
> >*/
> >   amdgpu_dm_crtc_handle_crc_irq(>base);
> >
> > - if (acrtc_state->stream &&
> > + if (acrtc_state->stream && adev->family >= AMDGPU_FAMILY_AI &&
> >   acrtc_state->vrr_params.supported &&
> >   acrtc_state->freesync_config.state == 
> > VRR_STATE_ACTIVE_VARIABLE) {
> > + spin_lock_irqsave(>ddev->event_lock, flags);
> >

[PATCH 2/3] drm/amd/display: Enter VRR BTR earlier.

2019-04-26 Thread Mario Kleiner

Use a 2 msecs switching headroom not only for slightly
delayed exiting of BTR mode, but now also for entering
it a bit before the max frame duration is exceeded.

With slowly changing time delay between successive flips
or with a bit of jitter in arrival of flips, this adapts
vblank early and prevents missed vblanks at the border
between non-BTR and BTR.

Testing on DCE-8, DCE-11 and DCN-1.0 shows that this more
often avoids skipped frames when moving across the BTR
boundary, especially on DCE-8 and DCE-11 with the followup
commit for dealing with pre-DCE-12 hw.

Signed-off-by: Mario Kleiner 
---
 drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index e56543c36eba..a965ab5466dc 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -350,7 +350,7 @@ static void apply_below_the_range(struct core_freesync 
*core_freesync,
in_out_vrr->btr.frame_counter = 0;
in_out_vrr->btr.btr_active = false;
}
-   } else if (last_render_time_in_us > max_render_time_in_us) {
+   } else if (last_render_time_in_us + BTR_EXIT_MARGIN > 
max_render_time_in_us) {
/* Enter Below the Range */
in_out_vrr->btr.btr_active = true;
}
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/3] drm/amd/display: Fix and simplify apply_below_the_range()

2019-04-26 Thread Mario Kleiner

The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.

Signed-off-by: Mario Kleiner 
Reviewed-by: Nicholas Kazlauskas 
---
 drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 71274683da04..e56543c36eba 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -437,10 +437,8 @@ static void apply_below_the_range(struct core_freesync 
*core_freesync,
inserted_frame_duration_in_us = last_render_time_in_us /
frames_to_insert;
 
-   if (inserted_frame_duration_in_us <
-   (100 / in_out_vrr->max_refresh_in_uhz))
-   inserted_frame_duration_in_us =
-   (100 / in_out_vrr->max_refresh_in_uhz);
+   if (inserted_frame_duration_in_us < 
in_out_vrr->min_duration_in_us)
+   inserted_frame_duration_in_us = 
in_out_vrr->min_duration_in_us;
 
/* Cache the calculated variables */
in_out_vrr->btr.inserted_duration_in_us =
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v3)

2019-04-26 Thread Mario Kleiner

Pre-DCE12 needs special treatment for BTR / low framerate
compensation for more stable behaviour:

According to comments in the code and some testing on DCE-8
and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
programming with a lag of one frame, so the special BTR hw
programming for intermediate fixed duration frames must be
done inside the current frame at flip submission in atomic
commit tail, ie. one vblank earlier, and the fixed refresh
intermediate frame mode must be also terminated one vblank
earlier on pre-DCE12 display engines.

To achieve proper termination on < DCE-12 shift the point
when the switch-back from fixed vblank duration to variable
vblank duration happens from the start of VBLANK (vblank irq,
as done on DCE-12+) to back-porch or end of VBLANK (handled
by vupdate irq handler). We must leave the switch-back code
inside VBLANK irq for DCE12+, as before.

Doing this, we get much better behaviour of BTR for up-sweeps,
ie. going from short to long frame durations (~high to low fps)
and for constant framerate flips, as tested on DCE-8 and
DCE-11. Behaviour is still not quite as good as on DCN-1
though.

On down-sweeps, going from long to short frame durations
(low fps to high fps) < DCE-12 is a little bit improved,
although by far not as much as for up-sweeps and constant
fps.

v2: Fix some wrong locking, as pointed out by Nicholas.
v3: Simplify if-condition in vupdate-irq - nit by Nicholas.
Signed-off-by: Mario Kleiner 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 48 +--
 1 file changed, 44 insertions(+), 4 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 76b6e621793f..92b3c2cec7dd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -364,6 +364,7 @@ static void dm_vupdate_high_irq(void *interrupt_params)
struct amdgpu_device *adev = irq_params->adev;
struct amdgpu_crtc *acrtc;
struct dm_crtc_state *acrtc_state;
+   unsigned long flags;
 
acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
IRQ_TYPE_VUPDATE);
 
@@ -379,8 +380,25 @@ static void dm_vupdate_high_irq(void *interrupt_params)
 * page-flip completion events that have been queued to us
 * if a pageflip happened inside front-porch.
 */
-   if (amdgpu_dm_vrr_active(acrtc_state))
+   if (amdgpu_dm_vrr_active(acrtc_state)) {
drm_crtc_handle_vblank(>base);
+
+   /* BTR processing for pre-DCE12 ASICs */
+   if (acrtc_state->stream &&
+   adev->family < AMDGPU_FAMILY_AI) {
+   spin_lock_irqsave(>ddev->event_lock, 
flags);
+   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);
+   spin_unlock_irqrestore(>ddev->event_lock, 
flags);
+   }
+   }
}
 }
 
@@ -390,6 +408,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
struct amdgpu_device *adev = irq_params->adev;
struct amdgpu_crtc *acrtc;
struct dm_crtc_state *acrtc_state;
+   unsigned long flags;
 
acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
IRQ_TYPE_VBLANK);
 
@@ -412,9 +431,10 @@ static void dm_crtc_high_irq(void *interrupt_params)
 */
amdgpu_dm_crtc_handle_crc_irq(>base);
 
-   if (acrtc_state->stream &&
+   if (acrtc_state->stream && adev->family >= AMDGPU_FAMILY_AI &&
acrtc_state->vrr_params.supported &&
acrtc_state->freesync_config.state == 
VRR_STATE_ACTIVE_VARIABLE) {
+   spin_lock_irqsave(>ddev->event_lock, flags);
mod_freesync_handle_v_update(
adev->dm.freesync_module,
acrtc_state->stream,
@@ -424,6 +444,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
adev->dm.dc,
acrtc_state->stream,
_state->vrr_params.adjust);
+   spin_unlock_irqrestore(>ddev->event_lock, flags);
}
}
 }
@@ -4878,8 +4899,10 @@ static void update_freesync_state_on_stream(
struct dc_plane_state *surface,
u32 flip_timestamp_in_us)
 {
-   struct mod_vrr_params vrr_params = new_crtc_state->vrr_params;
+

VRR BTR patches revision 3

2019-04-26 Thread Mario Kleiner

Same as rev 2, except for patch 3/3 v3 to apply Nicholas
latest feedback into account. Retested on DCN1 and DCE8.

thanks,
-mario


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: print firmware versions on amdgpu sysfs

2019-04-26 Thread Russell, Kent

The main reasoning and use case for sysfs would be the SMI CLI, since 
unfortunately there is no ioctl support in there.

Kent

KENT RUSSELL
Sr. Software Engineer | Linux Compute Kernel
1 Commerce Valley Drive East
Markham, ON L3T 7X6
O +(1) 289-695-2122 | Ext 72122

From: amd-gfx  on behalf of Deucher, 
Alexander 
Sent: Friday, April 26, 2019 12:18:22 PM
To: Lin, Amber; amd-gfx@lists.freedesktop.org
Cc: Freehill, Chris
Subject: Re: print firmware versions on amdgpu sysfs

We also expose the firmware versions via ioctl which is what the UMDs uses.  If 
you'd prefer it in sysfs, we could do that too.

Alex


From: amd-gfx  on behalf of Lin, Amber 

Sent: Friday, April 26, 2019 10:14 AM
To: amd-gfx@lists.freedesktop.org
Cc: Freehill, Chris
Subject: print firmware versions on amdgpu sysfs

Hi Alex,

Currently we retrieve firmware versions from /sys/kernel/debug but this
requires debugfs being enabled and superuser privilege. Do you see a
concern we add firmware versions to amdgpu sysfs at
/sys/class/drm/cardX/device like vbios_version?

Regards,
Amber
___
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: Expose DRM_FORMAT_RGB565 on overlay planes

2019-04-26 Thread Francis, David

Reviewed-by: David Francis 


From: amd-gfx  on behalf of Deucher, 
Alexander 
Sent: April 23, 2019 10:47:26 AM
To: Kazlauskas, Nicholas; amd-gfx@lists.freedesktop.org
Cc: Li, Sun peng (Leo); Wentland, Harry
Subject: Re: [PATCH] drm/amd/display: Expose DRM_FORMAT_RGB565 on overlay planes

Acked-by: Alex Deucher 

From: amd-gfx  on behalf of Nicholas 
Kazlauskas 
Sent: Tuesday, April 23, 2019 10:40 AM
To: amd-gfx@lists.freedesktop.org
Cc: Li, Sun peng (Leo); Wentland, Harry; Kazlauskas, Nicholas
Subject: [PATCH] drm/amd/display: Expose DRM_FORMAT_RGB565 on overlay planes

RGB565 support isn't restricted to just the primary plane in DC, so
also expose support for it on overlays.

Cc: Harry Wentland 
Cc: Leo Li 
Signed-off-by: Nicholas Kazlauskas 
---
 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 a5cacf846e1b..0d07226ca8b7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4283,6 +4283,7 @@ static const uint32_t overlay_formats[] = {
 DRM_FORMAT_RGBA,
 DRM_FORMAT_XBGR,
 DRM_FORMAT_ABGR,
+   DRM_FORMAT_RGB565
 };

 static const u32 cursor_formats[] = {
--
2.17.1

___
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 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v2)

2019-04-26 Thread Kazlauskas, Nicholas

On 4/26/19 6:50 AM, Mario Kleiner wrote:
> Pre-DCE12 needs special treatment for BTR / low framerate
> compensation for more stable behaviour:
> 
> According to comments in the code and some testing on DCE-8
> and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
> programming with a lag of one frame, so the special BTR hw
> programming for intermediate fixed duration frames must be
> done inside the current frame at flip submission in atomic
> commit tail, ie. one vblank earlier, and the fixed refresh
> intermediate frame mode must be also terminated one vblank
> earlier on pre-DCE12 display engines.
> 
> To achieve proper termination on < DCE-12 shift the point
> when the switch-back from fixed vblank duration to variable
> vblank duration happens from the start of VBLANK (vblank irq,
> as done on DCE-12+) to back-porch or end of VBLANK (handled
> by vupdate irq handler). We must leave the switch-back code
> inside VBLANK irq for DCE12+, as before.
> 
> Doing this, we get much better behaviour of BTR for up-sweeps,
> ie. going from short to long frame durations (~high to low fps)
> and for constant framerate flips, as tested on DCE-8 and
> DCE-11. Behaviour is still not quite as good as on DCN-1
> though.
> 
> On down-sweeps, going from long to short frame durations
> (low fps to high fps) < DCE-12 is a little bit improved,
> although by far not as much as for up-sweeps and constant
> fps.
> 
> v2: Fix some wrong locking, as pointed out by Nicholas.
> Signed-off-by: Mario Kleiner 

Still looks good to me, but I just noticed one other minor nitpick (sorry!)

> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 45 +--
>   1 file changed, 42 insertions(+), 3 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 76b6e621793f..7241e1f3ebec 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -364,6 +364,7 @@ static void dm_vupdate_high_irq(void *interrupt_params)
>   struct amdgpu_device *adev = irq_params->adev;
>   struct amdgpu_crtc *acrtc;
>   struct dm_crtc_state *acrtc_state;
> + unsigned long flags;
>   
>   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> IRQ_TYPE_VUPDATE);
>   
> @@ -381,6 +382,22 @@ static void dm_vupdate_high_irq(void *interrupt_params)
>*/
>   if (amdgpu_dm_vrr_active(acrtc_state))
>   drm_crtc_handle_vblank(>base);

Can't this block be merged with the one below?

With the condition also changed to just:

if (acrtc_state->stream && adev->family < AMDGPU_FAMILY_AI)
...

I also noticed that the crtc_state itself is always accessed unlocked 
for checking whether VRR is on/off which is probably a bug... but this 
patch shouldn't be the one to fix that. At the very least though it can 
leave things in a bit better shape like you've already done. Thanks!

Nicholas Kazlauskas

> +
> + if (acrtc_state->stream && adev->family < AMDGPU_FAMILY_AI &&
> + acrtc_state->vrr_params.supported &&
> + acrtc_state->freesync_config.state == 
> VRR_STATE_ACTIVE_VARIABLE) {
> + spin_lock_irqsave(>ddev->event_lock, flags);
> + 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);
> + spin_unlock_irqrestore(>ddev->event_lock, flags);
> + }
>   }
>   }
>   
> @@ -390,6 +407,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
>   struct amdgpu_device *adev = irq_params->adev;
>   struct amdgpu_crtc *acrtc;
>   struct dm_crtc_state *acrtc_state;
> + unsigned long flags;
>   
>   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> IRQ_TYPE_VBLANK);
>   
> @@ -412,9 +430,10 @@ static void dm_crtc_high_irq(void *interrupt_params)
>*/
>   amdgpu_dm_crtc_handle_crc_irq(>base);
>   
> - if (acrtc_state->stream &&
> + if (acrtc_state->stream && adev->family >= AMDGPU_FAMILY_AI &&
>   acrtc_state->vrr_params.supported &&
>   acrtc_state->freesync_config.state == 
> VRR_STATE_ACTIVE_VARIABLE) {
> + spin_lock_irqsave(>ddev->event_lock, flags);
>   mod_freesync_handle_v_update(
>   adev->dm.freesync_module,
>   acrtc_state->stream,
> @@ -424,6 +443,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
>   adev->dm.dc,
>

Re: [PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

2019-04-26 Thread Catalin Marinas

On Mon, Apr 01, 2019 at 06:44:34PM +0200, Andrey Konovalov wrote:
> On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas  
> wrote:
> > On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> > > @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long 
> > > addr,
> > >   if (opt == PR_SET_MM_AUXV)
> > >   return prctl_set_auxv(mm, addr, arg4);
> > >
> > > - if (addr >= TASK_SIZE || addr < mmap_min_addr)
> > > + if (untagged_addr(addr) >= TASK_SIZE ||
> > > + untagged_addr(addr) < mmap_min_addr)
> > >   return -EINVAL;
> > >
> > >   error = -EINVAL;
> > >
> > >   down_write(>mmap_sem);
> > > - vma = find_vma(mm, addr);
> > > + vma = find_vma(mm, untagged_addr(addr));
> > >
> > >   prctl_map.start_code= mm->start_code;
> > >   prctl_map.end_code  = mm->end_code;
> >
> > Does this mean that we are left with tagged addresses for the
> > mm->start_code etc. values? I really don't think we should allow this,
> > I'm not sure what the implications are in other parts of the kernel.
> >
> > Arguably, these are not even pointer values but some address ranges. I
> > know we decided to relax this notion for mmap/mprotect/madvise() since
> > the user function prototypes take pointer as arguments but it feels like
> > we are overdoing it here (struct prctl_mm_map doesn't even have
> > pointers).
> >
> > What is the use-case for allowing tagged addresses here? Can user space
> > handle untagging?
> 
> I don't know any use cases for this. I did it because it seems to be
> covered by the relaxed ABI. I'm not entirely sure what to do here,
> should I just drop this patch?

If we allow tagged addresses to be passed here, we'd have to untag them
before they end up in the mm->start_code etc. members.

I know we are trying to relax the ABI here w.r.t. address ranges but
mostly because we couldn't figure out a way to document unambiguously
the difference between a user pointer that may be dereferenced by the
kernel (tags allowed) and an address typically used for managing the
address space layout. Suggestions welcomed.

I'd say just drop this patch and capture it in the ABI document.

-- 
Catalin
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-26 Thread Arnd Bergmann

On Thu, Apr 25, 2019 at 11:25 PM Johannes Berg
 wrote:
> On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> > On Thu, Apr 25, 2019 at 5:35 PM Al Viro  wrote:
> > >
> > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> > >
> > > > If I understand your patch description well, using compat_ptr_ioctl
> > > > only works if the driver is not for s390, right?
> > >
> > > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > > and be done with that; compat_ptr() is a no-op anyway" breaks.  IOW,
> > > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > > that thing works on all biarch architectures, as long as all stuff
> > > handled by ->ioctl() takes pointer to arch-independent object as
> > > argument.  IOW,
> > > argument ignored => OK
> > > any arithmetical type => no go, compat_ptr() would bugger it
> > > pointer to int => OK
> > > pointer to string => OK
> > > pointer to u64 => OK
> > > pointer to struct {u64 addr; char s[11];} => OK
> >
> > To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> > case is also broken on x86, because sizeof (obj) is smaller
> > on i386, even though the location of the members are
> > the same. i.e. you can copy_from_user() this
>
> Actually, you can't even do that because the struct might sit at the end
> of a page and then you'd erroneously fault in this case.
>
> We had this a while ago with struct ifreq, see commit 98406133dd and its
> parents.

Yes, you are right. Very rare to hit with real-life code, but easily
reproduced by intentionally hitting it and clearly a bug.

As the saying goes

  | the difference between "always works" and "almost always works"
  | is called data corruption

here the difference is an -EFAULT.

  Arnd
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: print firmware versions on amdgpu sysfs

2019-04-26 Thread Deucher, Alexander

We also expose the firmware versions via ioctl which is what the UMDs uses.  If 
you'd prefer it in sysfs, we could do that too.

Alex

From: amd-gfx  on behalf of Lin, Amber 

Sent: Friday, April 26, 2019 10:14 AM
To: amd-gfx@lists.freedesktop.org
Cc: Freehill, Chris
Subject: print firmware versions on amdgpu sysfs

Hi Alex,

Currently we retrieve firmware versions from /sys/kernel/debug but this
requires debugfs being enabled and superuser privilege. Do you see a
concern we add firmware versions to amdgpu sysfs at
/sys/class/drm/cardX/device like vbios_version?

Regards,
Amber
___
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: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/

2019-04-26 Thread Daniel Vetter

On Fri, Apr 26, 2019 at 12:56:48PM +1000, Dave Airlie wrote:
> Daniel, drm-misc-next-fixes?

Makes sense. Pushed.

Cheers, Daniel

> 
> Dave.
> 
> On Fri, 26 Apr 2019 at 12:25,  wrote:
> >
> > Hi Dave,
> >
> > > -Original Message-
> > > From: Dave Airlie [mailto:airl...@gmail.com]
> > > Sent: Friday, April 26, 2019 11:19 AM
> > > To: Yamada, Masahiro/山田 真弘 
> > > Cc: David Airlie ; Daniel Vetter ;
> > > dri-devel ; nouveau
> > > ; Sam Ravnborg ; David
> > > (ChunMing) Zhou ; amd-gfx mailing list
> > > ; James (Qian) Wang
> > > ; Ben Skeggs ;
> > > linux-arm-msm ; Intel Graphics
> > > Development ;
> > > intel-gvt-...@lists.freedesktop.org; Linux Kernel Mailing List
> > > ; Christian König
> > > ; Alex Deucher ;
> > > freedr...@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with
> > > $(srctree)/
> > >
> > > On Fri, 26 Apr 2019 at 11:46, Masahiro Yamada
> > >  wrote:
> > > >
> > > > Hi.
> > > >
> > > >
> > > > On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
> > > >  wrote:
> > > > >
> > > > > Currently, the Kbuild core manipulates header search paths in a crazy
> > > > > way [1].
> > > > >
> > > > > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> > > > > the search paths in the srctree. Some Makefiles are already written
> > > in
> > > > > that way, but not all. The goal of this work is to make the notation
> > > > > consistent, and finally get rid of the gross hacks.
> > > > >
> > > > > Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> > > > > ("kbuild: do not drop -I without parameter").
> > > > >
> > > > > [1]: https://patchwork.kernel.org/patch/9632347/
> > > > >
> > > > > Signed-off-by: Masahiro Yamada 
> > > > > Reviewed-by: Sam Ravnborg 
> > > > > ---
> > > > >
> > > > > I put all gpu/drm changes into a single patch because
> > > > > they are trivial conversion.
> > > > >
> > > > > If you are interested in the big picture of this work,
> > > > > the full patch set is available at the following URL.
> > > > >
> > > > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.g
> > > it build-test
> > > >
> > > >
> > > > Is somebody taking care of this?
> > > >
> > >
> > > Are you expecting this to be merged in the drm tree? if so please
> > > indicate that when posting.
> >
> >
> > Sorry for unclearness.
> >
> > Could you apply this to your drm tree?
> >
> > Thanks.
> >
> >
> >
> >
> > > I'd assumed this would go via kbuild tree.
> > >
> > > If the later,
> > > Acked-by: Dave Airlie 
> > > Dave.

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

2019-04-26 Thread Deucher, Alexander

How about an interface to change the timeout on a per engine (gfx, compute, 
dma, etc.) basis?
amdgpu.lockup_timeout=,
if only one parameter is given, we change it globably.  If more are given, we 
override the global one.  Could also do a sysfs interface to change it on the 
fly.

Alex

From: amd-gfx  on behalf of Michel 
Dänzer 
Sent: Friday, April 26, 2019 4:35 AM
To: Quan, Evan; Koenig, Christian
Cc: Xu, Feifei; Cui, Flora; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

On 2019-04-26 10:20 a.m., Quan, Evan wrote:
> My concern is there is already one module parameter "lockup_timeout".
> parm:   lockup_timeout:GPU lockup timeout in ms > 0 (default 1) 
> (int)
>
> Adding one more "timeout" seems redundant.
> And that will makes the description of "lockup_timeout"(seems working for all 
> jobs) does not match its real effect(affect only non-compute jobs).
>
> A better way is to rename "lockup_timeout" to "non-compute lockup_timeout". 
> But I do not think we can change existing module parameter. Right?

Right. Also, there are already too many amdgpu module parameters, we
should try to remove some rather than adding new ones for every little
thing that could be tweaked. :)

One possibility might be to optionally allow passing multiple values to
lockup_timeout, e.g.

 amdgpu.lockup_timeout=1,0

The first value would need to have the same meaning as now for backwards
compatibility.

--
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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

print firmware versions on amdgpu sysfs

2019-04-26 Thread Lin, Amber

Hi Alex,

Currently we retrieve firmware versions from /sys/kernel/debug but this 
requires debugfs being enabled and superuser privilege. Do you see a 
concern we add firmware versions to amdgpu sysfs at 
/sys/class/drm/cardX/device like vbios_version?

Regards,
Amber
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.

2019-04-26 Thread Grodzovsky, Andrey

Ping (mostly David and Monk).

Andrey

On 4/24/19 3:09 AM, Christian König wrote:
Am 24.04.19 um 05:02 schrieb Zhou, David(ChunMing):
>> -drm_sched_stop(>sched, >base);
>> -
>>   /* after all hw jobs are reset, hw fence is meaningless, so 
>> force_completion */
>>   amdgpu_fence_driver_force_completion(ring);
>>   }

HW fence are already forced completion, then we can just disable irq fence 
process and ignore hw fence signal when we are trying to do GPU reset, I think. 
Otherwise which will make the logic much more complex.
If this situation happens because of long time execution, we can increase 
timeout of reset detection.

You are not thinking widely enough, forcing the hw fence to complete can 
trigger other to start other activity in the system.

We first need to stop everything and make sure that we don't do any processing 
any more and then start with our reset procedure including forcing all hw 
fences to complete.

Christian.

-David

From: amd-gfx 

 On Behalf Of Grodzovsky, Andrey
Sent: Wednesday, April 24, 2019 12:00 AM
To: Zhou, David(ChunMing) ; 
dri-de...@lists.freedesktop.org; 
amd-gfx@lists.freedesktop.org; 
e...@anholt.net; 
etna...@lists.freedesktop.org; 
ckoenig.leichtzumer...@gmail.com
Cc: Kazlauskas, Nicholas 
; Liu, Monk 

Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already 
signaled.

No, i mean the actual HW fence which signals when the job finished execution on 
the HW.

Andrey
On 4/23/19 11:19 AM, Zhou, David(ChunMing) wrote:
do you mean fence timer? why not stop it as well when stopping sched for the 
reason of hw reset?

 Original Message 
Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already 
signaled.
From: "Grodzovsky, Andrey"
To: "Zhou, David(ChunMing)" 
,dri-de...@lists.freedesktop.org,amd-gfx@lists.freedesktop.org,e...@anholt.net,etna...@lists.freedesktop.org,ckoenig.leichtzumer...@gmail.com
CC: "Kazlauskas, Nicholas" ,"Liu, Monk"

On 4/22/19 9:09 AM, Zhou, David(ChunMing) wrote:
> +Monk.
>
> GPU reset is used widely in SRIOV, so need virtulizatino guy take a look.
>
> But out of curious, why guilty job can signal more if the job is already
> set to guilty? set it wrongly?
>
>
> -David

It's possible that the job does completes at a later time then it's
timeout handler started processing so in this patch we try to protect
against this by rechecking the HW fence after stopping all SW
schedulers. We do it BEFORE marking guilty on the job's sched_entity so
at the point we check the guilty flag is not set yet.

Andrey

>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> Also reject TDRs if another one already running.
>>
>> v2:
>> Stop all schedulers across device and entire XGMI hive before
>> force signaling HW fences.
>> Avoid passing job_signaled to helper fnctions to keep all the decision
>> making about skipping HW reset in one place.
>>
>> v3:
>> Fix SW sched. hang after non HW reset. sched.hw_rq_count has to be balanced
>> against it's decrement in drm_sched_stop in non HW reset case.
>> v4: rebase
>> v5: Revert v3 as we do it now in sceduler code.
>>
>> Signed-off-by: Andrey Grodzovsky 
>> 
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 143 
>> +++--
>>1 file changed, 95 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index a0e165c..85f8792 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3334,8 +3334,6 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>   if (!ring || !ring->sched.thread)
>>   continue;
>>
>> -drm_sched_stop(>sched, >base);
>> -
>>   /* after all hw jobs are reset, hw fence is meaningless, so 
>> force_completion */
>>   amdgpu_fence_driver_force_completion(ring);
>>   }
>> @@ -3343,6 +3341,7 @@ static int amdgpu_device_pre_asic_reset(struct 
>> amdgpu_device *adev,
>>   if(job)
>>   drm_sched_increase_karma(>base);
>>
>> +/* Don't suspend on bare metal if we are not going to HW reset the ASIC 
>> */
>>   if (!amdgpu_sriov_vf(adev)) {
>>
>>   if (!need_full_reset)
>> @@ -3480,37 +3479,21 @@ static int amdgpu_do_asic_reset(struct 
>> amdgpu_hive_info *hive,
>>   return r;
>>}
>>
>> -static void

Re: [PATCH v2 7/9] iommu/vt-d: use helper pci_dev_id

2019-04-26 Thread Joerg Roedel

On Wed, Apr 24, 2019 at 09:16:10PM +0200, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
> 
> Signed-off-by: Heiner Kallweit 

Reviewed-by: Joerg Roedel 

> ---
>  drivers/iommu/intel-iommu.c | 2 +-
>  drivers/iommu/intel_irq_remapping.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index d93c4bd7d..3f475a23a 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -1391,7 +1391,7 @@ static void iommu_enable_dev_iotlb(struct 
> device_domain_info *info)
>  
>   /* pdev will be returned if device is not a vf */
>   pf_pdev = pci_physfn(pdev);
> - info->pfsid = PCI_DEVID(pf_pdev->bus->number, pf_pdev->devfn);
> + info->pfsid = pci_dev_id(pf_pdev);
>   }
>  
>  #ifdef CONFIG_INTEL_IOMMU_SVM
> diff --git a/drivers/iommu/intel_irq_remapping.c 
> b/drivers/iommu/intel_irq_remapping.c
> index 634d8f059..4160aa9f3 100644
> --- a/drivers/iommu/intel_irq_remapping.c
> +++ b/drivers/iommu/intel_irq_remapping.c
> @@ -424,7 +424,7 @@ static int set_msi_sid(struct irte *irte, struct pci_dev 
> *dev)
>   set_irte_sid(irte, SVT_VERIFY_SID_SQ, SQ_ALL_16, data.alias);
>   else
>   set_irte_sid(irte, SVT_VERIFY_SID_SQ, SQ_ALL_16,
> -  PCI_DEVID(dev->bus->number, dev->devfn));
> +  pci_dev_id(dev));
>  
>   return 0;
>  }
> -- 
> 2.21.0
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 6/9] iommu/amd: use helper pci_dev_id

2019-04-26 Thread Joerg Roedel

On Wed, Apr 24, 2019 at 09:15:25PM +0200, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
> 
> Signed-off-by: Heiner Kallweit 

Reviewed-by: Joerg Roedel 

> ---
>  drivers/iommu/amd_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index f467cc4b4..5cb201422 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -165,7 +165,7 @@ static inline u16 get_pci_device_id(struct device *dev)
>  {
>   struct pci_dev *pdev = to_pci_dev(dev);
>  
> - return PCI_DEVID(pdev->bus->number, pdev->devfn);
> + return pci_dev_id(pdev);
>  }
>  
>  static inline int get_acpihid_device_id(struct device *dev,
> -- 
> 2.21.0
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v2)

2019-04-26 Thread Mario Kleiner

Pre-DCE12 needs special treatment for BTR / low framerate
compensation for more stable behaviour:

According to comments in the code and some testing on DCE-8
and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
programming with a lag of one frame, so the special BTR hw
programming for intermediate fixed duration frames must be
done inside the current frame at flip submission in atomic
commit tail, ie. one vblank earlier, and the fixed refresh
intermediate frame mode must be also terminated one vblank
earlier on pre-DCE12 display engines.

To achieve proper termination on < DCE-12 shift the point
when the switch-back from fixed vblank duration to variable
vblank duration happens from the start of VBLANK (vblank irq,
as done on DCE-12+) to back-porch or end of VBLANK (handled
by vupdate irq handler). We must leave the switch-back code
inside VBLANK irq for DCE12+, as before.

Doing this, we get much better behaviour of BTR for up-sweeps,
ie. going from short to long frame durations (~high to low fps)
and for constant framerate flips, as tested on DCE-8 and
DCE-11. Behaviour is still not quite as good as on DCN-1
though.

On down-sweeps, going from long to short frame durations
(low fps to high fps) < DCE-12 is a little bit improved,
although by far not as much as for up-sweeps and constant
fps.

v2: Fix some wrong locking, as pointed out by Nicholas.
Signed-off-by: Mario Kleiner 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 45 +--
 1 file changed, 42 insertions(+), 3 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 76b6e621793f..7241e1f3ebec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -364,6 +364,7 @@ static void dm_vupdate_high_irq(void *interrupt_params)
struct amdgpu_device *adev = irq_params->adev;
struct amdgpu_crtc *acrtc;
struct dm_crtc_state *acrtc_state;
+   unsigned long flags;
 
acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
IRQ_TYPE_VUPDATE);
 
@@ -381,6 +382,22 @@ static void dm_vupdate_high_irq(void *interrupt_params)
 */
if (amdgpu_dm_vrr_active(acrtc_state))
drm_crtc_handle_vblank(>base);
+
+   if (acrtc_state->stream && adev->family < AMDGPU_FAMILY_AI &&
+   acrtc_state->vrr_params.supported &&
+   acrtc_state->freesync_config.state == 
VRR_STATE_ACTIVE_VARIABLE) {
+   spin_lock_irqsave(>ddev->event_lock, flags);
+   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);
+   spin_unlock_irqrestore(>ddev->event_lock, flags);
+   }
}
 }
 
@@ -390,6 +407,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
struct amdgpu_device *adev = irq_params->adev;
struct amdgpu_crtc *acrtc;
struct dm_crtc_state *acrtc_state;
+   unsigned long flags;
 
acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
IRQ_TYPE_VBLANK);
 
@@ -412,9 +430,10 @@ static void dm_crtc_high_irq(void *interrupt_params)
 */
amdgpu_dm_crtc_handle_crc_irq(>base);
 
-   if (acrtc_state->stream &&
+   if (acrtc_state->stream && adev->family >= AMDGPU_FAMILY_AI &&
acrtc_state->vrr_params.supported &&
acrtc_state->freesync_config.state == 
VRR_STATE_ACTIVE_VARIABLE) {
+   spin_lock_irqsave(>ddev->event_lock, flags);
mod_freesync_handle_v_update(
adev->dm.freesync_module,
acrtc_state->stream,
@@ -424,6 +443,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
adev->dm.dc,
acrtc_state->stream,
_state->vrr_params.adjust);
+   spin_unlock_irqrestore(>ddev->event_lock, flags);
}
}
 }
@@ -4878,8 +4898,10 @@ static void update_freesync_state_on_stream(
struct dc_plane_state *surface,
u32 flip_timestamp_in_us)
 {
-   struct mod_vrr_params vrr_params = new_crtc_state->vrr_params;
+   struct mod_vrr_params vrr_params;
struct dc_info_packet vrr_infopacket = {0};
+   struct amdgpu_device *adev = dm->adev;
+   unsigned long flags;
 
if (!new_stream)
return;
@@ -4892,6 +4914,9 @@ static void update_freesync_state_on_stream(
if (!new_stream->timing.h_total ||

[PATCH 2/3] drm/amd/display: Enter VRR BTR earlier.

2019-04-26 Thread Mario Kleiner

Use a 2 msecs switching headroom not only for slightly
delayed exiting of BTR mode, but now also for entering
it a bit before the max frame duration is exceeded.

With slowly changing time delay between successive flips
or with a bit of jitter in arrival of flips, this adapts
vblank early and prevents missed vblanks at the border
between non-BTR and BTR.

Testing on DCE-8, DCE-11 and DCN-1.0 shows that this more
often avoids skipped frames when moving across the BTR
boundary, especially on DCE-8 and DCE-11 with the followup
commit for dealing with pre-DCE-12 hw.

Signed-off-by: Mario Kleiner 
---
 drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index e56543c36eba..a965ab5466dc 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -350,7 +350,7 @@ static void apply_below_the_range(struct core_freesync 
*core_freesync,
in_out_vrr->btr.frame_counter = 0;
in_out_vrr->btr.btr_active = false;
}
-   } else if (last_render_time_in_us > max_render_time_in_us) {
+   } else if (last_render_time_in_us + BTR_EXIT_MARGIN > 
max_render_time_in_us) {
/* Enter Below the Range */
in_out_vrr->btr.btr_active = true;
}
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/3] drm/amd/display: Fix and simplify apply_below_the_range()

2019-04-26 Thread Mario Kleiner

The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.

Signed-off-by: Mario Kleiner 
Reviewed-by: Nicholas Kazlauskas 
---
 drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 71274683da04..e56543c36eba 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -437,10 +437,8 @@ static void apply_below_the_range(struct core_freesync 
*core_freesync,
inserted_frame_duration_in_us = last_render_time_in_us /
frames_to_insert;
 
-   if (inserted_frame_duration_in_us <
-   (100 / in_out_vrr->max_refresh_in_uhz))
-   inserted_frame_duration_in_us =
-   (100 / in_out_vrr->max_refresh_in_uhz);
+   if (inserted_frame_duration_in_us < 
in_out_vrr->min_duration_in_us)
+   inserted_frame_duration_in_us = 
in_out_vrr->min_duration_in_us;
 
/* Cache the calculated variables */
in_out_vrr->btr.inserted_duration_in_us =
-- 
2.20.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

VRR BTR patches revision 2

2019-04-26 Thread Mario Kleiner

Updated series. The debug patch is dropped, a r-b by Nicholas is tacked
onto patch 1/3 and patch 3/3 has the locking fix that Nicholas proposed.
In terms of testing 3/3 didn't change anything for the better or worse,
observed behaviour on retested DCN-1 and DCE-8 is the same.
Patch 2/3 is identical.

For reference i made a little git repo with a cleaned up version
of my test script VRRTest.m and some pdf's with some plots from my
testing with a slightly earlier version of that script:

https://github.com/kleinerm/VRRTestPlots

Easy to use on a Debian/Ubuntu based system as you can get GNU/Octave
+ psychtoolbox-3 from the distro repo. Explanations in the Readm

The following plots illustrate how patch 2/3 can sometimes help to
make transition to BTR a bit smoother min VRR was 25 Hz or 40 msecs
in this test case on DCE8 and 30 Hz or 33 msecs on DCE11.

Without patch 2/3:

https://github.com/kleinerm/VRRTestPlots/blob/master/VRR_DCE8_2upstepping_VUPDATEbtr+removehysteresispatch.pdf
https://github.com/kleinerm/VRRTestPlots/blob/master/VRR_DCE11_2upstepping_VUPDATEbtr+removehysteresispatch.pdf

With patch 2/3:

https://github.com/kleinerm/VRRTestPlots/blob/master/VRR_DCE11_2upstepping_VUPDATEbtr.pdf
https://github.com/kleinerm/VRRTestPlots/blob/master/VRR_DCE8_2upstepping_VUPDATEbtr.pdf

-mario


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 4/4] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations.

2019-04-26 Thread Mario Kleiner

On Wed, Apr 24, 2019 at 4:34 PM Kazlauskas, Nicholas
 wrote:
>
> On 4/17/19 11:51 PM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some testing on DCE-8
> > and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
> > programming with a lag of one frame, so the special BTR hw
> > programming for intermediate fixed duration frames must be
> > done inside the current frame at flip submission in atomic
> > commit tail, ie. one vblank earlier, and the fixed refresh
> > intermediate frame mode must be also terminated one vblank
> > earlier on pre-DCE12 display engines.
> >
> > To achieve proper termination on < DCE-12 shift the point
> > when the switch-back from fixed vblank duration to variable
> > vblank duration happens from the start of VBLANK (vblank irq,
> > as done on DCE-12+) to back-porch or end of VBLANK (handled
> > by vupdate irq handler). We must leave the switch-back code
> > inside VBLANK irq for DCE12+, as before.
> >
> > Doing this, we get much better behaviour of BTR for up-sweeps,
> > ie. going from short to long frame durations (~high to low fps)
> > and for constant framerate flips, as tested on DCE-8 and
> > DCE-11. Behaviour is still not quite as good as on DCN-1
> > though.
> >
> > On down-sweeps, going from long to short frame durations
> > (low fps to high fps) < DCE-12 is a little bit improved,
> > although by far not as much as for up-sweeps and constant
> > fps.
> >
> > Signed-off-by: Mario Kleiner 
> > ---
>
> I did some debugging/testing with this patch and it certainly does
> improve things quite a bit for pre DCE12 (since this really should have
> been handled in VUPDATE before).
>

Do you know at which exact point in the frame cycle or vblank the new
VTOTAL_MIN/MAX gets latched by the hw?

Btw. for reference i made a little git repo with a cleaned up version
my test script VRRTest.m and some pdf's with some plots from my
testing with a slightly earlier version of that script:

https://github.com/kleinerm/VRRTestPlots

Easy to use on a Debian/Ubuntu based system as you can get GNU/Octave
+ psychtoolbox-3 from the distro repo. Explanations in the Readme.md

> I have one comment inline below:
>
>
> >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 ++-
> >   1 file changed, 31 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 76b6e621793f..9c8c94f82b35 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -364,6 +364,7 @@ static void dm_vupdate_high_irq(void *interrupt_params)
> >   struct amdgpu_device *adev = irq_params->adev;
> >   struct amdgpu_crtc *acrtc;
> >   struct dm_crtc_state *acrtc_state;
> > + unsigned long flags;
> >
> >   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> > IRQ_TYPE_VUPDATE);
> >
> > @@ -381,6 +382,22 @@ static void dm_vupdate_high_irq(void *interrupt_params)
> >*/
> >   if (amdgpu_dm_vrr_active(acrtc_state))
> >   drm_crtc_handle_vblank(>base);
> > +
> > + if (acrtc_state->stream && adev->family < AMDGPU_FAMILY_AI &&
> > + acrtc_state->vrr_params.supported &&
> > + acrtc_state->freesync_config.state == 
> > VRR_STATE_ACTIVE_VARIABLE) {
> > + spin_lock_irqsave(>ddev->event_lock, flags);
> > + 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);
> > + spin_unlock_irqrestore(>ddev->event_lock, 
> > flags);
> > + }
> >   }
> >   }
> >
> > @@ -390,6 +407,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
> >   struct amdgpu_device *adev = irq_params->adev;
> >   struct amdgpu_crtc *acrtc;
> >   struct dm_crtc_state *acrtc_state;
> > + unsigned long flags;
> >
> >   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> > IRQ_TYPE_VBLANK);
> >
> > @@ -412,9 +430,10 @@ static void dm_crtc_high_irq(void *interrupt_params)
> >*/
> >   amdgpu_dm_crtc_handle_crc_irq(>base);
> >
> > - if (acrtc_state->stream &&
> > + if (acrtc_state->stream && adev->family >= AMDGPU_FAMILY_AI &&
> >   acrtc_state->vrr_params.supported &&
> >   acrtc_state->freesync_config.state == 
> > VRR_STATE_ACTIVE_VARIABLE) {
> > + spin_lock_irqsave(>ddev->event_lock, flags);
> >

Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

2019-04-26 Thread Michel Dänzer

On 2019-04-26 10:20 a.m., Quan, Evan wrote:
> My concern is there is already one module parameter "lockup_timeout".
> parm:   lockup_timeout:GPU lockup timeout in ms > 0 (default 1) 
> (int)
> 
> Adding one more "timeout" seems redundant. 
> And that will makes the description of "lockup_timeout"(seems working for all 
> jobs) does not match its real effect(affect only non-compute jobs).
> 
> A better way is to rename "lockup_timeout" to "non-compute lockup_timeout". 
> But I do not think we can change existing module parameter. Right?

Right. Also, there are already too many amdgpu module parameters, we
should try to remove some rather than adding new ones for every little
thing that could be tweaked. :)

One possibility might be to optionally allow passing multiple values to
lockup_timeout, e.g.

 amdgpu.lockup_timeout=1,0

The first value would need to have the same meaning as now for backwards
compatibility.

-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

2019-04-26 Thread Christian König


Am 26.04.19 um 10:20 schrieb Quan, Evan:

My concern is there is already one module parameter "lockup_timeout".
parm:   lockup_timeout:GPU lockup timeout in ms > 0 (default 1) 
(int)

Adding one more "timeout" seems redundant.
And that will makes the description of "lockup_timeout"(seems working for all 
jobs) does not match its real effect(affect only non-compute jobs).

A better way is to rename "lockup_timeout" to "non-compute lockup_timeout". But 
I do not think we can change existing module parameter. Right?


No, that's fine. Module parameters are not part of the API which needs 
to stay backward compatible.


Maybe use compute_lockup_timeout and other_lockup_timeout or something 
similar?


Regards,
Christian.



Regards,
Evan

-Original Message-
From: amd-gfx  On Behalf Of
Christian K?nig
Sent: Friday, April 26, 2019 3:34 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Xu, Feifei ; Cui, Flora 
Subject: Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute
rings

Am 26.04.19 um 09:24 schrieb Evan Quan:

A new module parameter is added for determining whether or not to
enforce timeout on compute jobs.

Can we rework that a bit and instead of a bool have a separate millisecond
timeout for compute?

E.g. default is 0 and that means MAX_SCHEDULE_TIMEOUT unless we are
under SRIOV.
Any other value is just the timeout in milliseconds.

Christian.


Change-Id: If14b75977312e42dac0431072456e5b69cf1bc2f
Signed-off-by: Evan Quan 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 +
   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 8 
   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 3 ++-
   3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index e16dcee2bf75..ee624d993df7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -166,6 +166,7 @@ extern int amdgpu_si_support;
   #ifdef CONFIG_DRM_AMDGPU_CIK
   extern int amdgpu_cik_support;
   #endif
+extern bool amdgpu_compute_timeout_enforced;

   #define AMDGPU_VM_MAX_NUM_CTX4096
   #define AMDGPU_SG_THRESHOLD  (256*1024*1024)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 13a68f62bcc8..91de3e90fae9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -140,6 +140,7 @@ struct amdgpu_mgpu_info mgpu_info = {
   };
   int amdgpu_ras_enable = -1;
   uint amdgpu_ras_mask = 0x;
+bool amdgpu_compute_timeout_enforced = false;

   /**
* DOC: vramlimit (int)
@@ -234,6 +235,13 @@ module_param_named(msi, amdgpu_msi, int,

0444);

   MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms > 0

(default 1)");

   module_param_named(lockup_timeout, amdgpu_lockup_timeout, int,
0444);

+/**
+ * DOC: compute_timeout_enforced (bool)
+ * Whether or not to enforce timeout on compute jobs (1 = enable, 0 =

disable). The default is 0.

+ */
+MODULE_PARM_DESC(compute_timeout_enforced, "Enforce timeout

on

+compute jobs (1 = enable, 0 = disable (default))");
+module_param_named(compute_timeout_enforced,
+amdgpu_compute_timeout_enforced, bool, 0444);
+
   /**
* DOC: dpm (int)
* Override for dynamic power management setting (1 = enable, 0 =

disable). The default is -1 (auto).

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 4dee2326b29c..4adffad04dbc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -453,7 +453,8 @@ int amdgpu_fence_driver_init_ring(struct

amdgpu_ring *ring,

if (ring->funcs->type != AMDGPU_RING_TYPE_KIQ) {
/* for non-sriov case, no timeout enforce on compute ring */
if ((ring->funcs->type == AMDGPU_RING_TYPE_COMPUTE)
-   && !amdgpu_sriov_vf(ring->adev))
+   && !amdgpu_sriov_vf(ring->adev)
+   && !amdgpu_compute_timeout_enforced)
timeout = MAX_SCHEDULE_TIMEOUT;
else
timeout =

msecs_to_jiffies(amdgpu_lockup_timeout);

___
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


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

2019-04-26 Thread Quan, Evan

My concern is there is already one module parameter "lockup_timeout".
parm:   lockup_timeout:GPU lockup timeout in ms > 0 (default 1) 
(int)

Adding one more "timeout" seems redundant. 
And that will makes the description of "lockup_timeout"(seems working for all 
jobs) does not match its real effect(affect only non-compute jobs).

A better way is to rename "lockup_timeout" to "non-compute lockup_timeout". But 
I do not think we can change existing module parameter. Right?

Regards,
Evan
> -Original Message-
> From: amd-gfx  On Behalf Of
> Christian K?nig
> Sent: Friday, April 26, 2019 3:34 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Xu, Feifei ; Cui, Flora 
> Subject: Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute
> rings
> 
> Am 26.04.19 um 09:24 schrieb Evan Quan:
> > A new module parameter is added for determining whether or not to
> > enforce timeout on compute jobs.
> 
> Can we rework that a bit and instead of a bool have a separate millisecond
> timeout for compute?
> 
> E.g. default is 0 and that means MAX_SCHEDULE_TIMEOUT unless we are
> under SRIOV.
> Any other value is just the timeout in milliseconds.
> 
> Christian.
> 
> >
> > Change-Id: If14b75977312e42dac0431072456e5b69cf1bc2f
> > Signed-off-by: Evan Quan 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 8 
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 3 ++-
> >   3 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index e16dcee2bf75..ee624d993df7 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -166,6 +166,7 @@ extern int amdgpu_si_support;
> >   #ifdef CONFIG_DRM_AMDGPU_CIK
> >   extern int amdgpu_cik_support;
> >   #endif
> > +extern bool amdgpu_compute_timeout_enforced;
> >
> >   #define AMDGPU_VM_MAX_NUM_CTX 4096
> >   #define AMDGPU_SG_THRESHOLD   (256*1024*1024)
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index 13a68f62bcc8..91de3e90fae9 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -140,6 +140,7 @@ struct amdgpu_mgpu_info mgpu_info = {
> >   };
> >   int amdgpu_ras_enable = -1;
> >   uint amdgpu_ras_mask = 0x;
> > +bool amdgpu_compute_timeout_enforced = false;
> >
> >   /**
> >* DOC: vramlimit (int)
> > @@ -234,6 +235,13 @@ module_param_named(msi, amdgpu_msi, int,
> 0444);
> >   MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms > 0
> (default 1)");
> >   module_param_named(lockup_timeout, amdgpu_lockup_timeout, int,
> > 0444);
> >
> > +/**
> > + * DOC: compute_timeout_enforced (bool)
> > + * Whether or not to enforce timeout on compute jobs (1 = enable, 0 =
> disable). The default is 0.
> > + */
> > +MODULE_PARM_DESC(compute_timeout_enforced, "Enforce timeout
> on
> > +compute jobs (1 = enable, 0 = disable (default))");
> > +module_param_named(compute_timeout_enforced,
> > +amdgpu_compute_timeout_enforced, bool, 0444);
> > +
> >   /**
> >* DOC: dpm (int)
> >* Override for dynamic power management setting (1 = enable, 0 =
> disable). The default is -1 (auto).
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > index 4dee2326b29c..4adffad04dbc 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > @@ -453,7 +453,8 @@ int amdgpu_fence_driver_init_ring(struct
> amdgpu_ring *ring,
> > if (ring->funcs->type != AMDGPU_RING_TYPE_KIQ) {
> > /* for non-sriov case, no timeout enforce on compute ring */
> > if ((ring->funcs->type == AMDGPU_RING_TYPE_COMPUTE)
> > -   && !amdgpu_sriov_vf(ring->adev))
> > +   && !amdgpu_sriov_vf(ring->adev)
> > +   && !amdgpu_compute_timeout_enforced)
> > timeout = MAX_SCHEDULE_TIMEOUT;
> > else
> > timeout =
> msecs_to_jiffies(amdgpu_lockup_timeout);
> 
> ___
> 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: support gpu recovery tests on compute rings

2019-04-26 Thread Christian König


Am 26.04.19 um 09:24 schrieb Evan Quan:

A new module parameter is added for determining
whether or not to enforce timeout on compute jobs.


Can we rework that a bit and instead of a bool have a separate 
millisecond timeout for compute?


E.g. default is 0 and that means MAX_SCHEDULE_TIMEOUT unless we are 
under SRIOV.

Any other value is just the timeout in milliseconds.

Christian.



Change-Id: If14b75977312e42dac0431072456e5b69cf1bc2f
Signed-off-by: Evan Quan 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 8 
  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 3 ++-
  3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index e16dcee2bf75..ee624d993df7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -166,6 +166,7 @@ extern int amdgpu_si_support;
  #ifdef CONFIG_DRM_AMDGPU_CIK
  extern int amdgpu_cik_support;
  #endif
+extern bool amdgpu_compute_timeout_enforced;
  
  #define AMDGPU_VM_MAX_NUM_CTX			4096

  #define AMDGPU_SG_THRESHOLD   (256*1024*1024)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 13a68f62bcc8..91de3e90fae9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -140,6 +140,7 @@ struct amdgpu_mgpu_info mgpu_info = {
  };
  int amdgpu_ras_enable = -1;
  uint amdgpu_ras_mask = 0x;
+bool amdgpu_compute_timeout_enforced = false;
  
  /**

   * DOC: vramlimit (int)
@@ -234,6 +235,13 @@ module_param_named(msi, amdgpu_msi, int, 0444);
  MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms > 0 (default 
1)");
  module_param_named(lockup_timeout, amdgpu_lockup_timeout, int, 0444);
  
+/**

+ * DOC: compute_timeout_enforced (bool)
+ * Whether or not to enforce timeout on compute jobs (1 = enable, 0 = 
disable). The default is 0.
+ */
+MODULE_PARM_DESC(compute_timeout_enforced, "Enforce timeout on compute jobs (1 = 
enable, 0 = disable (default))");
+module_param_named(compute_timeout_enforced, amdgpu_compute_timeout_enforced, 
bool, 0444);
+
  /**
   * DOC: dpm (int)
   * Override for dynamic power management setting (1 = enable, 0 = disable). 
The default is -1 (auto).
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 4dee2326b29c..4adffad04dbc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -453,7 +453,8 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring *ring,
if (ring->funcs->type != AMDGPU_RING_TYPE_KIQ) {
/* for non-sriov case, no timeout enforce on compute ring */
if ((ring->funcs->type == AMDGPU_RING_TYPE_COMPUTE)
-   && !amdgpu_sriov_vf(ring->adev))
+   && !amdgpu_sriov_vf(ring->adev)
+   && !amdgpu_compute_timeout_enforced)
timeout = MAX_SCHEDULE_TIMEOUT;
else
timeout = msecs_to_jiffies(amdgpu_lockup_timeout);


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: support gpu recovery tests on compute rings

2019-04-26 Thread Evan Quan

A new module parameter is added for determining
whether or not to enforce timeout on compute jobs.

Change-Id: If14b75977312e42dac0431072456e5b69cf1bc2f
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 3 ++-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index e16dcee2bf75..ee624d993df7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -166,6 +166,7 @@ extern int amdgpu_si_support;
 #ifdef CONFIG_DRM_AMDGPU_CIK
 extern int amdgpu_cik_support;
 #endif
+extern bool amdgpu_compute_timeout_enforced;
 
 #define AMDGPU_VM_MAX_NUM_CTX  4096
 #define AMDGPU_SG_THRESHOLD(256*1024*1024)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 13a68f62bcc8..91de3e90fae9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -140,6 +140,7 @@ struct amdgpu_mgpu_info mgpu_info = {
 };
 int amdgpu_ras_enable = -1;
 uint amdgpu_ras_mask = 0x;
+bool amdgpu_compute_timeout_enforced = false;
 
 /**
  * DOC: vramlimit (int)
@@ -234,6 +235,13 @@ module_param_named(msi, amdgpu_msi, int, 0444);
 MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms > 0 (default 
1)");
 module_param_named(lockup_timeout, amdgpu_lockup_timeout, int, 0444);
 
+/**
+ * DOC: compute_timeout_enforced (bool)
+ * Whether or not to enforce timeout on compute jobs (1 = enable, 0 = 
disable). The default is 0.
+ */
+MODULE_PARM_DESC(compute_timeout_enforced, "Enforce timeout on compute jobs (1 
= enable, 0 = disable (default))");
+module_param_named(compute_timeout_enforced, amdgpu_compute_timeout_enforced, 
bool, 0444);
+
 /**
  * DOC: dpm (int)
  * Override for dynamic power management setting (1 = enable, 0 = disable). 
The default is -1 (auto).
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 4dee2326b29c..4adffad04dbc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -453,7 +453,8 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring *ring,
if (ring->funcs->type != AMDGPU_RING_TYPE_KIQ) {
/* for non-sriov case, no timeout enforce on compute ring */
if ((ring->funcs->type == AMDGPU_RING_TYPE_COMPUTE)
-   && !amdgpu_sriov_vf(ring->adev))
+   && !amdgpu_sriov_vf(ring->adev)
+   && !amdgpu_compute_timeout_enforced)
timeout = MAX_SCHEDULE_TIMEOUT;
else
timeout = msecs_to_jiffies(amdgpu_lockup_timeout);
-- 
2.21.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/

2019-04-26 Thread yamada.masahiro

Hi Dave,

> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Friday, April 26, 2019 11:19 AM
> To: Yamada, Masahiro/山田 真弘 
> Cc: David Airlie ; Daniel Vetter ;
> dri-devel ; nouveau
> ; Sam Ravnborg ; David
> (ChunMing) Zhou ; amd-gfx mailing list
> ; James (Qian) Wang
> ; Ben Skeggs ;
> linux-arm-msm ; Intel Graphics
> Development ;
> intel-gvt-...@lists.freedesktop.org; Linux Kernel Mailing List
> ; Christian König
> ; Alex Deucher ;
> freedr...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with
> $(srctree)/
> 
> On Fri, 26 Apr 2019 at 11:46, Masahiro Yamada
>  wrote:
> >
> > Hi.
> >
> >
> > On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
> >  wrote:
> > >
> > > Currently, the Kbuild core manipulates header search paths in a crazy
> > > way [1].
> > >
> > > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> > > the search paths in the srctree. Some Makefiles are already written
> in
> > > that way, but not all. The goal of this work is to make the notation
> > > consistent, and finally get rid of the gross hacks.
> > >
> > > Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> > > ("kbuild: do not drop -I without parameter").
> > >
> > > [1]: https://patchwork.kernel.org/patch/9632347/
> > >
> > > Signed-off-by: Masahiro Yamada 
> > > Reviewed-by: Sam Ravnborg 
> > > ---
> > >
> > > I put all gpu/drm changes into a single patch because
> > > they are trivial conversion.
> > >
> > > If you are interested in the big picture of this work,
> > > the full patch set is available at the following URL.
> > >
> > >
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.g
> it build-test
> >
> >
> > Is somebody taking care of this?
> >
> 
> Are you expecting this to be merged in the drm tree? if so please
> indicate that when posting.


Sorry for unclearness.

Could you apply this to your drm tree?

Thanks.




> I'd assumed this would go via kbuild tree.
> 
> If the later,
> Acked-by: Dave Airlie 
> Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 4/9] powerpc/powernv/npu: use helper pci_dev_id

2019-04-26 Thread Alexey Kardashevskiy



On 25/04/2019 05:14, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
> 
> Signed-off-by: Heiner Kallweit 



Reviewed-by: Alexey Kardashevskiy 


> ---
>  arch/powerpc/platforms/powernv/npu-dma.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
> b/arch/powerpc/platforms/powernv/npu-dma.c
> index dc23d9d2a..495550432 100644
> --- a/arch/powerpc/platforms/powernv/npu-dma.c
> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> @@ -1213,9 +1213,8 @@ int pnv_npu2_map_lpar_dev(struct pci_dev *gpdev, 
> unsigned int lparid,
>* Currently we only support radix and non-zero LPCR only makes sense
>* for hash tables so skiboot expects the LPCR parameter to be a zero.
>*/
> - ret = opal_npu_map_lpar(nphb->opal_id,
> - PCI_DEVID(gpdev->bus->number, gpdev->devfn), lparid,
> - 0 /* LPCR bits */);
> + ret = opal_npu_map_lpar(nphb->opal_id, pci_dev_id(gpdev), lparid,
> + 0 /* LPCR bits */);
>   if (ret) {
>   dev_err(>dev, "Error %d mapping device to LPAR\n", ret);
>   return ret;
> @@ -1224,7 +1223,7 @@ int pnv_npu2_map_lpar_dev(struct pci_dev *gpdev, 
> unsigned int lparid,
>   dev_dbg(>dev, "init context opalid=%llu msr=%lx\n",
>   nphb->opal_id, msr);
>   ret = opal_npu_init_context(nphb->opal_id, 0/*__unused*/, msr,
> - PCI_DEVID(gpdev->bus->number, gpdev->devfn));
> + pci_dev_id(gpdev));
>   if (ret < 0)
>   dev_err(>dev, "Failed to init context: %d\n", ret);
>   else
> @@ -1258,7 +1257,7 @@ int pnv_npu2_unmap_lpar_dev(struct pci_dev *gpdev)
>   dev_dbg(>dev, "destroy context opalid=%llu\n",
>   nphb->opal_id);
>   ret = opal_npu_destroy_context(nphb->opal_id, 0/*__unused*/,
> - PCI_DEVID(gpdev->bus->number, gpdev->devfn));
> +pci_dev_id(gpdev));
>   if (ret < 0) {
>   dev_err(>dev, "Failed to destroy context: %d\n", ret);
>   return ret;
> @@ -1266,9 +1265,8 @@ int pnv_npu2_unmap_lpar_dev(struct pci_dev *gpdev)
>  
>   /* Set LPID to 0 anyway, just to be safe */
>   dev_dbg(>dev, "Map LPAR opalid=%llu lparid=0\n", nphb->opal_id);
> - ret = opal_npu_map_lpar(nphb->opal_id,
> - PCI_DEVID(gpdev->bus->number, gpdev->devfn), 0 /*LPID*/,
> - 0 /* LPCR bits */);
> + ret = opal_npu_map_lpar(nphb->opal_id, pci_dev_id(gpdev), 0 /*LPID*/,
> + 0 /* LPCR bits */);
>   if (ret)
>   dev_err(>dev, "Error %d mapping device to LPAR\n", ret);
>  
> 

-- 
Alexey
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2] drm: prefix header search paths with $(srctree)/

2019-04-26 Thread Masahiro Yamada

Hi.


On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
 wrote:
>
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way, but not all. The goal of this work is to make the notation
> consistent, and finally get rid of the gross hacks.
>
> Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> ("kbuild: do not drop -I without parameter").
>
> [1]: https://patchwork.kernel.org/patch/9632347/
>
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Sam Ravnborg 
> ---
>
> I put all gpu/drm changes into a single patch because
> they are trivial conversion.
>
> If you are interested in the big picture of this work,
> the full patch set is available at the following URL.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git 
> build-test


Is somebody taking care of this?



>
> Changes in v2:
>   - fix up the new driver komeda
>   - Add Sam's Reviewed-by
>
>  drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
>  drivers/gpu/drm/amd/lib/Makefile| 2 +-
>  drivers/gpu/drm/arm/display/komeda/Makefile | 4 ++--
>  drivers/gpu/drm/i915/gvt/Makefile   | 2 +-
>  drivers/gpu/drm/msm/Makefile| 6 +++---
>  drivers/gpu/drm/nouveau/Kbuild  | 8 
>  6 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index 466da59..62bf9da 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -23,7 +23,7 @@
>  # Makefile for the drm device driver.  This driver provides support for the
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
> -FULL_AMD_PATH=$(src)/..
> +FULL_AMD_PATH=$(srctree)/$(src)/..
>  DISPLAY_FOLDER_NAME=display
>  FULL_AMD_DISPLAY_PATH = $(FULL_AMD_PATH)/$(DISPLAY_FOLDER_NAME)
>
> diff --git a/drivers/gpu/drm/amd/lib/Makefile 
> b/drivers/gpu/drm/amd/lib/Makefile
> index 6902430..d534992 100644
> --- a/drivers/gpu/drm/amd/lib/Makefile
> +++ b/drivers/gpu/drm/amd/lib/Makefile
> @@ -27,6 +27,6 @@
>  # driver components or later moved to kernel/lib for sharing with
>  # other drivers.
>
> -ccflags-y := -I$(src)/../include
> +ccflags-y := -I $(srctree)/$(src)/../include
>
>  obj-$(CONFIG_CHASH) += chash.o
> diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
> b/drivers/gpu/drm/arm/display/komeda/Makefile
> index 1b875e5..a72e30c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> @@ -1,8 +1,8 @@
>  # SPDX-License-Identifier: GPL-2.0
>
>  ccflags-y := \
> -   -I$(src)/../include \
> -   -I$(src)
> +   -I $(srctree)/$(src)/../include \
> +   -I $(srctree)/$(src)
>
>  komeda-y := \
> komeda_drv.o \
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> b/drivers/gpu/drm/i915/gvt/Makefile
> index 271fb46..ea8324a 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -5,5 +5,5 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
> trace_points.o firmware.o \
> execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
> debugfs.o \
> fb_decoder.o dmabuf.o page_track.o
>
> -ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR)
> +ccflags-y  += -I $(srctree)/$(src) -I 
> $(srctree)/$(src)/$(GVT_DIR)/
>  i915-y += $(addprefix $(GVT_DIR)/, 
> $(GVT_SOURCE))
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index 56a70c7..b7b1ebd 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -1,7 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
> -ccflags-y := -Idrivers/gpu/drm/msm
> -ccflags-y += -Idrivers/gpu/drm/msm/disp/dpu1
> -ccflags-$(CONFIG_DRM_MSM_DSI) += -Idrivers/gpu/drm/msm/dsi
> +ccflags-y := -I $(srctree)/$(src)
> +ccflags-y += -I $(srctree)/$(src)/disp/dpu1
> +ccflags-$(CONFIG_DRM_MSM_DSI) += -I $(srctree)/$(src)/dsi
>
>  msm-y := \
> adreno/adreno_device.o \
> diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
> index ea3035e..4fae728 100644
> --- a/drivers/gpu/drm/nouveau/Kbuild
> +++ b/drivers/gpu/drm/nouveau/Kbuild
> @@ -1,7 +1,7 @@
> -ccflags-y += -I$(src)/include
> -ccflags-y += -I$(src)/include/nvkm
> -ccflags-y += -I$(src)/nvkm
> -ccflags-y += -I$(src)
> +ccflags-y += -I $(srctree)/$(src)/include
> +ccflags-y += -I $(srctree)/$(src)/include/nvkm
> +ccflags-y += -I $(srctree)/$(src)/nvkm
> +ccflags-y += -I $(srctree)/$(src)
>
>  # NVKM - HW resource manager
>  #- code also used by various userspace tools/tests
> --
> 2.7.4
>


-- 
Best Regards
Masahiro Yamada
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org

[PATCH AUTOSEL 4.19 30/53] drm/amd/display: fix cursor black issue

[PATCH AUTOSEL 4.19 29/53] drm/amdkfd: Add picasso pci id

[PATCH AUTOSEL 5.0 40/79] drm/amdgpu: amdgpu_device_recover_vram always failed if only one node in shadow_list

[PATCH AUTOSEL 5.0 39/79] drm/amdgpu: Adjust IB test timeout for XGMI configuration

[PATCH AUTOSEL 5.0 41/79] drm/amd/display: fix cursor black issue

[PATCH AUTOSEL 5.0 38/79] drm/amdkfd: Add picasso pci id

Re: [PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v2)

[PATCH 2/3] drm/amd/display: Enter VRR BTR earlier.

[PATCH 1/3] drm/amd/display: Fix and simplify apply_below_the_range()

[PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v3)

VRR BTR patches revision 3

Re: print firmware versions on amdgpu sysfs

Re: [PATCH] drm/amd/display: Expose DRM_FORMAT_RGB565 on overlay planes

Re: [PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v2)

Re: [PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

Re: print firmware versions on amdgpu sysfs

Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/

Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

print firmware versions on amdgpu sysfs

Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.

Re: [PATCH v2 7/9] iommu/vt-d: use helper pci_dev_id

Re: [PATCH v2 6/9] iommu/amd: use helper pci_dev_id

[PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v2)

[PATCH 2/3] drm/amd/display: Enter VRR BTR earlier.

[PATCH 1/3] drm/amd/display: Fix and simplify apply_below_the_range()

VRR BTR patches revision 2

Re: [PATCH 4/4] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations.

Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

RE: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

[PATCH] drm/amdgpu: support gpu recovery tests on compute rings

RE: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/

Re: [PATCH v2 4/9] powerpc/powernv/npu: use helper pci_dev_id

Re: [PATCH v2] drm: prefix header search paths with $(srctree)/

36 matches

Site Navigation

Mail list logo

Footer information