Re: [PATCH] drm/amdgpu: Fix size calculation when init onchip memory

2020-10-23 Thread Christian König 

Am 23.10.20 um 07:41 schrieb xinhui pan:

Size is page count here.

Signed-off-by: xinhui pan 


Ah yes that one again. At some point we really need to clean that up.

Patch is Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 4a85f8cedd77..11dd3d9eac15 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -65,11 +65,11 @@
  
  static int amdgpu_ttm_init_on_chip(struct amdgpu_device *adev,

unsigned int type,
-   uint64_t size)
+   uint64_t size_in_page)
  {
return ttm_range_man_init(&adev->mman.bdev, type,
  TTM_PL_FLAG_UNCACHED, TTM_PL_FLAG_UNCACHED,
- false, size >> PAGE_SHIFT);
+ false, size_in_page);
  }
  
  /**


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

Re: kgdb_breakpoint() usage leads to kernel panic

2020-10-23 Thread Takashi Iwai 
On Thu, 22 Oct 2020 11:03:43 +0200,
Takashi Iwai wrote:
> 
> Hi,
> 
> we recently stumbled on a kernel crash in amdgpu [*], and the kernel
> messages indicated that it's from kgdb_breakpoint() call in
> ASSERT_CRITICAL() macro.
> 
> Since CONFIG_KGDB=y is set on the openSUSE distro kernels, the
> breakpoint is enabled even though CONFIG_DEBUG_KERNEL_DC=n, and this
> leads to a kernel panic because of INT3.  Unfortunately there is no
> dynamical control to disable it.
> 
> I guess the kernel panic isn't intended for end-users, right?  If so,
> shouldn't we cover kgdb_breakpoint() in ASSERT_CRITICAL() also with
> CONFIG_DEBUG_KERNEL_DC?
> 
> Also, taking a quick glance at the code, I noticed a few things:
> 
> - What's the difference of ASSERT() and ASSERT_CRITICAL()?
>   Why ASSERT() uses WARN_ON() and WARN_ON_ONCE() conditionally?
> 
> - I couldn't see CONFIG_HAVE_KGDB anywhere else.  Is this superfluous?
> 
> - CONFIG_DEBUG_KERNEL_DC can have "depends on KGDB" in Kconfig.
>   Then the ifdefs can be much simplified.
> 
> 
> [*] https://bugzilla.suse.com/show_bug.cgi?id=1177973

As there's no reply, I'm going to submit the fix patches.


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

[PATCH 3/3] drm/amd/display: Clean up debug macros

2020-10-23 Thread Takashi Iwai 
This patch simplifies the ASSERT*() and BREAK_TO_DEBUGGER() macros:
- Move the dependency check of CONFIG_KGDB into Kconfig
- Unify the kgdb_breakpoint() call
- Drop the non-existing CONFIG_HAVE_KGDB

Also align the behavior of ASSERT() macro in both cases with and
without CONFIG_DEBUG_KERNEL_DC.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/amd/display/Kconfig   |  1 +
 drivers/gpu/drm/amd/display/dc/os_types.h | 33 +++
 2 files changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig 
b/drivers/gpu/drm/amd/display/Kconfig
index f24abf428534..60dfdd432aba 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -42,6 +42,7 @@ config DRM_AMD_DC_SI
 config DEBUG_KERNEL_DC
bool "Enable kgdb break in DC"
depends on DRM_AMD_DC
+   depends on KGDB
help
  Choose this option if you want to hit kdgb_break in assert.
 
diff --git a/drivers/gpu/drm/amd/display/dc/os_types.h 
b/drivers/gpu/drm/amd/display/dc/os_types.h
index 32758b245754..95cb56929e79 100644
--- a/drivers/gpu/drm/amd/display/dc/os_types.h
+++ b/drivers/gpu/drm/amd/display/dc/os_types.h
@@ -94,36 +94,27 @@
  * general debug capabilities
  *
  */
-#if defined(CONFIG_DEBUG_KERNEL_DC) && (defined(CONFIG_HAVE_KGDB) || 
defined(CONFIG_KGDB))
-#define ASSERT_CRITICAL(expr) do { \
-   if (WARN_ON(!(expr))) { \
-   kgdb_breakpoint(); \
-   } \
-} while (0)
+#ifdef CONFIG_DEBUG_KERNEL_DC
+#define dc_breakpoint()kgdb_breakpoint()
 #else
-#define ASSERT_CRITICAL(expr) do { \
-   if (WARN_ON(!(expr))) { \
-   ; \
-   } \
-} while (0)
+#define dc_breakpoint()do {} while (0)
 #endif
 
-#if defined(CONFIG_DEBUG_KERNEL_DC)
-#define ASSERT(expr) ASSERT_CRITICAL(expr)
+#define ASSERT_CRITICAL(expr) do { \
+   if (WARN_ON(!(expr)))   \
+   dc_breakpoint();\
+   } while (0)
 
-#else
-#define ASSERT(expr) WARN_ON_ONCE(!(expr))
-#endif
+#define ASSERT(expr) do {  \
+   if (WARN_ON_ONCE(!(expr)))  \
+   dc_breakpoint();\
+   } while (0)
 
-#if defined(CONFIG_DEBUG_KERNEL_DC) && (defined(CONFIG_HAVE_KGDB) || 
defined(CONFIG_KGDB))
 #define BREAK_TO_DEBUGGER() \
do { \
DRM_DEBUG_DRIVER("%s():%d\n", __func__, __LINE__); \
-   kgdb_breakpoint(); \
+   dc_breakpoint(); \
} while (0)
-#else
-#define BREAK_TO_DEBUGGER() DRM_DEBUG_DRIVER("%s():%d\n", __func__, __LINE__)
-#endif
 
 #define DC_ERR(...)  do { \
dm_error(__VA_ARGS__); \
-- 
2.16.4

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

[PATCH 0/3] drm/amd/display: Fix kernel panic by breakpoint

2020-10-23 Thread Takashi Iwai 
Hi,

the amdgpu driver's ASSERT_CRITICAL() macro calls the
kgdb_breakpoing() even if no debug option is set, and this leads to a
kernel panic on distro kernels.  The first two patches are the
oneliner fixes for those, while the last one is the cleanup of those
debug macros.


Takashi

===

Takashi Iwai (3):
  drm/amd/display: Fix kernel panic by dal_gpio_open() error
  drm/amd/display: Don't invoke kgdb_breakpoint() unconditionally
  drm/amd/display: Clean up debug macros

 drivers/gpu/drm/amd/display/Kconfig |  1 +
 drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c |  4 +--
 drivers/gpu/drm/amd/display/dc/os_types.h   | 33 +
 3 files changed, 15 insertions(+), 23 deletions(-)

-- 
2.16.4

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

[PATCH 2/3] drm/amd/display: Don't invoke kgdb_breakpoint() unconditionally

2020-10-23 Thread Takashi Iwai 
ASSERT_CRITICAL() invokes kgdb_breakpoint() whenever either
CONFIG_KGDB or CONFIG_HAVE_KGDB is set.  This, however, may lead to a
kernel panic when no kdb stuff is attached, since the
kgdb_breakpoint() call issues INT3.  It's nothing but a surprise for
normal end-users.

For avoiding the pitfall, make the kgdb_breakpoint() call only when
CONFIG_DEBUG_KERNEL_DC is set.

https://bugzilla.opensuse.org/show_bug.cgi?id=1177973
Cc: 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/amd/display/dc/os_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/os_types.h 
b/drivers/gpu/drm/amd/display/dc/os_types.h
index 330acaaed79a..32758b245754 100644
--- a/drivers/gpu/drm/amd/display/dc/os_types.h
+++ b/drivers/gpu/drm/amd/display/dc/os_types.h
@@ -94,7 +94,7 @@
  * general debug capabilities
  *
  */
-#if defined(CONFIG_HAVE_KGDB) || defined(CONFIG_KGDB)
+#if defined(CONFIG_DEBUG_KERNEL_DC) && (defined(CONFIG_HAVE_KGDB) || 
defined(CONFIG_KGDB))
 #define ASSERT_CRITICAL(expr) do { \
if (WARN_ON(!(expr))) { \
kgdb_breakpoint(); \
-- 
2.16.4

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

[PATCH 1/3] drm/amd/display: Fix kernel panic by dal_gpio_open() error

2020-10-23 Thread Takashi Iwai 
Currently both error code paths handled in dal_gpio_open_ex() issues
ASSERT_CRITICAL(), and this leads to a kernel panic unnecessarily if
CONFIG_KGDB is enabled.  Since basically both are non-critical errors
and can be recovered, drop those assert calls and use a safer one,
BREAK_TO_DEBUGGER(), for allowing the debugging, instead.

BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1177973
Cc: 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c 
b/drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c
index f67c18375bfd..dac427b68fd7 100644
--- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c
+++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c
@@ -63,13 +63,13 @@ enum gpio_result dal_gpio_open_ex(
enum gpio_mode mode)
 {
if (gpio->pin) {
-   ASSERT_CRITICAL(false);
+   BREAK_TO_DEBUGGER();
return GPIO_RESULT_ALREADY_OPENED;
}
 
// No action if allocation failed during gpio construct
if (!gpio->hw_container.ddc) {
-   ASSERT_CRITICAL(false);
+   BREAK_TO_DEBUGGER();
return GPIO_RESULT_NON_SPECIFIC_ERROR;
}
gpio->mode = mode;
-- 
2.16.4

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

[PATCH] Revert "drm/amdgpu: IP discovery table is not ready yet for VG"

2020-10-23 Thread Xiaomeng Hou 
This reverts commit ba502322c9f216552485cea967aeb8adbaf03a02.

IP discovery table has been verified on vangogh.

Signed-off-by: Xiaomeng Hou 
---
 drivers/gpu/drm/amd/amdgpu/nv.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 72435e0eb8b9..30ec826c8760 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -449,10 +449,6 @@ static int nv_reg_base_init(struct amdgpu_device *adev)
 {
int r;
 
-   /* IP discovery table is not available yet */
-   if (adev->asic_type == CHIP_VANGOGH)
-   goto legacy_init;
-
if (amdgpu_discovery) {
r = amdgpu_discovery_reg_base_init(adev);
if (r) {
-- 
2.17.1

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

Re: [PATCH] Revert "drm/amdgpu: IP discovery table is not ready yet for VG"

2020-10-23 Thread Huang Rui 
On Fri, Oct 23, 2020 at 04:21:15PM +0800, Hou, Xiaomeng (Matthew) wrote:
> This reverts commit ba502322c9f216552485cea967aeb8adbaf03a02.

I suggest you didn't highlight to revert a patch. Becasue previous commit
was good before, because it's the gap that firmware/sbios support.

Just modify the subject as "drm/amdgpu: enable IP discovery for vangogh",
that's enough.

With that fixed, patch is Reviewed-by: Huang Rui  

> 
> IP discovery table has been verified on vangogh.
> 
> Signed-off-by: Xiaomeng Hou 
> ---
>  drivers/gpu/drm/amd/amdgpu/nv.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
> index 72435e0eb8b9..30ec826c8760 100644
> --- a/drivers/gpu/drm/amd/amdgpu/nv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/nv.c
> @@ -449,10 +449,6 @@ static int nv_reg_base_init(struct amdgpu_device *adev)
>  {
>   int r;
>  
> - /* IP discovery table is not available yet */
> - if (adev->asic_type == CHIP_VANGOGH)
> - goto legacy_init;
> -
>   if (amdgpu_discovery) {
>   r = amdgpu_discovery_reg_base_init(adev);
>   if (r) {
> -- 
> 2.17.1
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 07/65] drm/vblank: Annotate with dma-fence signalling section

2020-10-23 Thread Daniel Vetter 
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index f135b79593dd..ba7e741764aa 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -24,6 +24,7 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1913,7 +1914,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
 {
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
unsigned long irqflags;
-   bool disable_irq;
+   bool disable_irq, fence_cookie;
 
if (drm_WARN_ON_ONCE(dev, !drm_dev_has_vblank(dev)))
return false;
@@ -1921,6 +1922,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return false;
 
+   fence_cookie = dma_fence_begin_signalling();
+
spin_lock_irqsave(&dev->event_lock, irqflags);
 
/* Need timestamp lock to prevent concurrent execution with
@@ -1933,6 +1936,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
if (!vblank->enabled) {
spin_unlock(&dev->vblank_time_lock);
spin_unlock_irqrestore(&dev->event_lock, irqflags);
+   dma_fence_end_signalling(fence_cookie);
return false;
}
 
@@ -1959,6 +1963,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
if (disable_irq)
vblank_disable_fn(&vblank->disable_timer);
 
+   dma_fence_end_signalling(fence_cookie);
+
return true;
 }
 EXPORT_SYMBOL(drm_handle_vblank);
-- 
2.28.0

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

[PATCH 06/65] drm/vkms: Annotate vblank timer

2020-10-23 Thread Daniel Vetter 
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.

Tested-by: Melissa Wen 
Reviewed-by: Rodrigo Siqueira 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index e43e4e1b268a..8124d8f2ee15 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -1,5 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 
+#include 
+
 #include 
 #include 
 #include 
@@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
hrtimer *timer)
struct drm_crtc *crtc = &output->crtc;
struct vkms_crtc_state *state;
u64 ret_overrun;
-   bool ret;
+   bool ret, fence_cookie;
+
+   fence_cookie = dma_fence_begin_signalling();
 
ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
  output->period_ns);
@@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
hrtimer *timer)
DRM_DEBUG_DRIVER("Composer worker already queued\n");
}
 
+   dma_fence_end_signalling(fence_cookie);
+
return HRTIMER_RESTART;
 }
 
-- 
2.28.0

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

[PATCH 05/65] drm/atomic-helper: Add dma-fence annotations

2020-10-23 Thread Daniel Vetter 
This is a bit disappointing since we need to split the annotations
over all the different parts.

I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
implementations of this hook right now), so bad flag day. And also a
bit leaky abstraction.

Hence just do it function-by-function.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 549a31e6042c..23013209d4bf 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1567,6 +1567,7 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
 void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
 {
struct drm_device *dev = old_state->dev;
+   bool fence_cookie = dma_fence_begin_signalling();
 
drm_atomic_helper_commit_modeset_disables(dev, old_state);
 
@@ -1578,6 +1579,8 @@ void drm_atomic_helper_commit_tail(struct 
drm_atomic_state *old_state)
 
drm_atomic_helper_commit_hw_done(old_state);
 
+   dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
 
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1597,6 +1600,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
 void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
 {
struct drm_device *dev = old_state->dev;
+   bool fence_cookie = dma_fence_begin_signalling();
 
drm_atomic_helper_commit_modeset_disables(dev, old_state);
 
@@ -1609,6 +1613,8 @@ void drm_atomic_helper_commit_tail_rpm(struct 
drm_atomic_state *old_state)
 
drm_atomic_helper_commit_hw_done(old_state);
 
+   dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
 
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1624,6 +1630,9 @@ static void commit_tail(struct drm_atomic_state 
*old_state)
ktime_t start;
s64 commit_time_ms;
unsigned int i, new_self_refresh_mask = 0;
+   bool fence_cookie;
+
+   fence_cookie = dma_fence_begin_signalling();
 
funcs = dev->mode_config.helper_private;
 
@@ -1652,6 +1661,8 @@ static void commit_tail(struct drm_atomic_state 
*old_state)
if (new_crtc_state->self_refresh_active)
new_self_refresh_mask |= BIT(i);
 
+   dma_fence_end_signalling(fence_cookie);
+
if (funcs && funcs->atomic_commit_tail)
funcs->atomic_commit_tail(old_state);
else
@@ -1810,6 +1821,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 bool nonblock)
 {
int ret;
+   bool fence_cookie;
 
if (state->async_update) {
ret = drm_atomic_helper_prepare_planes(dev, state);
@@ -1832,6 +1844,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (ret)
return ret;
 
+   fence_cookie = dma_fence_begin_signalling();
+
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret)
@@ -1869,6 +1883,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 */
 
drm_atomic_state_get(state);
+   dma_fence_end_signalling(fence_cookie);
if (nonblock)
queue_work(system_unbound_wq, &state->commit_work);
else
@@ -1877,6 +1892,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
return 0;
 
 err:
+   dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
 }
-- 
2.28.0

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

[PATCH 08/65] drm/amdgpu: add dma-fence annotations to atomic commit path

2020-10-23 Thread Daniel Vetter 
I need a canary in a ttm-based atomic driver to make sure the
dma_fence_begin/end_signalling annotations actually work.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++
 1 file changed, 6 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 bb1bc7f5d149..b05fecf06f25 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -57,6 +57,7 @@
 
 #include "ivsrcid/ivsrcid_vislands30.h"
 
+#include 
 #include 
 #include 
 #include 
@@ -7492,6 +7493,9 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state;
int crtc_disable_count = 0;
bool mode_set_reset_required = false;
+   bool fence_cookie;
+
+   fence_cookie = dma_fence_begin_signalling();
 
drm_atomic_helper_update_legacy_modeset_state(dev, state);
drm_atomic_helper_calc_timestamping_constants(state);
@@ -7816,6 +7820,8 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
/* Signal HW programming completion */
drm_atomic_helper_commit_hw_done(state);
 
+   dma_fence_end_signalling(fence_cookie);
+
if (wait_for_vblank)
drm_atomic_helper_wait_for_flip_done(dev, state);
 
-- 
2.28.0

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

[PATCH 19/65] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code

2020-10-23 Thread Daniel Vetter 
My dma-fence lockdep annotations caught an inversion because we
allocate memory where we really shouldn't:

kmem_cache_alloc+0x2b/0x6d0
amdgpu_fence_emit+0x30/0x330 [amdgpu]
amdgpu_ib_schedule+0x306/0x550 [amdgpu]
amdgpu_job_run+0x10f/0x260 [amdgpu]
drm_sched_main+0x1b9/0x490 [gpu_sched]
kthread+0x12e/0x150

Trouble right now is that lockdep only validates against GFP_FS, which
would be good enough for shrinkers. But for mmu_notifiers we actually
need !GFP_ATOMIC, since they can be called from any page laundering,
even if GFP_NOFS or GFP_NOIO are set.

I guess we should improve the lockdep annotations for
fs_reclaim_acquire/release.

Ofc real fix is to properly preallocate this fence and stuff it into
the amdgpu job structure. But GFP_ATOMIC gets the lockdep splat out of
the way.

v2: Two more allocations in scheduler paths.

Frist one:

__kmalloc+0x58/0x720
amdgpu_vmid_grab+0x100/0xca0 [amdgpu]
amdgpu_job_dependency+0xf9/0x120 [amdgpu]
drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched]
drm_sched_main+0xf9/0x490 [gpu_sched]

Second one:

kmem_cache_alloc+0x2b/0x6d0
amdgpu_sync_fence+0x7e/0x110 [amdgpu]
amdgpu_vmid_grab+0x86b/0xca0 [amdgpu]
amdgpu_job_dependency+0xf9/0x120 [amdgpu]
drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched]
drm_sched_main+0xf9/0x490 [gpu_sched]

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index fe2d495d08ab..09614b325b5f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -143,7 +143,7 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct 
dma_fence **f,
uint32_t seq;
int r;
 
-   fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL);
+   fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC);
if (fence == NULL)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
index 7521f4ab55de..2a4cde7cd746 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
@@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm,
if (ring->vmid_wait && !dma_fence_is_signaled(ring->vmid_wait))
return amdgpu_sync_fence(sync, ring->vmid_wait);
 
-   fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL);
+   fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_ATOMIC);
if (!fences)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index 8ea6c49529e7..af22b526cec9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
@@ -160,7 +160,7 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct 
dma_fence *f)
if (amdgpu_sync_add_later(sync, f))
return 0;
 
-   e = kmem_cache_alloc(amdgpu_sync_slab, GFP_KERNEL);
+   e = kmem_cache_alloc(amdgpu_sync_slab, GFP_ATOMIC);
if (!e)
return -ENOMEM;
 
-- 
2.28.0

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

[PATCH 17/65] drm/scheduler: use dma-fence annotations in main thread

2020-10-23 Thread Daniel Vetter 
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.

Add dma-fence annotations so that lockdep can check this for us.

I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no expert on drm scheduler.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/scheduler/sched_main.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 9a0d77a68018..f69abc4e70d3 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -764,9 +764,12 @@ static int drm_sched_main(void *param)
 {
struct drm_gpu_scheduler *sched = (struct drm_gpu_scheduler *)param;
int r;
+   bool fence_cookie;
 
sched_set_fifo_low(current);
 
+   fence_cookie = dma_fence_begin_signalling();
+
while (!kthread_should_stop()) {
struct drm_sched_entity *entity = NULL;
struct drm_sched_fence *s_fence;
@@ -824,6 +827,9 @@ static int drm_sched_main(void *param)
 
wake_up(&sched->job_scheduled);
}
+
+   dma_fence_end_signalling(fence_cookie);
+
return 0;
 }
 
-- 
2.28.0

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

[PATCH 18/65] drm/amdgpu: use dma-fence annotations in cs_submit()

2020-10-23 Thread Daniel Vetter 
This is a bit tricky, since ->notifier_lock is held while calling
dma_fence_wait we must ensure that also the read side (i.e.
dma_fence_begin_signalling) is on the same side. If we mix this up
lockdep complaints, and that's again why we want to have these
annotations.

A nice side effect of this is that because of the fs_reclaim priming
for dma_fence_enable lockdep now automatically checks for us that
nothing in here allocates memory, without even running any userptr
workloads.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d50b63a93d37..3b3999225e31 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1212,6 +1212,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
struct amdgpu_job *job;
uint64_t seq;
int r;
+   bool fence_cookie;
 
job = p->job;
p->job = NULL;
@@ -1226,6 +1227,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
 */
mutex_lock(&p->adev->notifier_lock);
 
+   fence_cookie = dma_fence_begin_signalling();
+
/* If userptr are invalidated after amdgpu_cs_parser_bos(), return
 * -EAGAIN, drmIoctl in libdrm will restart the amdgpu_cs_ioctl.
 */
@@ -1262,12 +1265,14 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
amdgpu_vm_move_to_lru_tail(p->adev, &fpriv->vm);
 
ttm_eu_fence_buffer_objects(&p->ticket, &p->validated, p->fence);
+   dma_fence_end_signalling(fence_cookie);
mutex_unlock(&p->adev->notifier_lock);
 
return 0;
 
 error_abort:
drm_sched_job_cleanup(&job->base);
+   dma_fence_end_signalling(fence_cookie);
mutex_unlock(&p->adev->notifier_lock);
 
 error_unlock:
-- 
2.28.0

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

[PATCH 20/65] drm/scheduler: use dma-fence annotations in tdr work

2020-10-23 Thread Daniel Vetter 
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.

Originally this was part of the overall scheduler annotation patch.
But amdgpu has some glorious inversions here:

- grabs console_lock
- does a full modeset, which grabs all kinds of locks
  (drm_modeset_lock, dma_resv_lock) which can deadlock with
  dma_fence_wait held inside them.
- almost minor at that point, but the modeset code also allocates
  memory

These all look like they'll be very hard to fix properly, the hardware
seems to require a full display reset with any gpu recovery.

Hence split out as a seperate patch.

Since amdgpu isn't the only hardware driver that needs to reset the
display (at least gen2/3 on intel have the same problem) we need a
generic solution for this. There's two tricks we could still from
drm/i915 and lift to dma-fence:

- The big whack, aka force-complete all fences. i915 does this for all
  pending jobs if the reset is somehow stuck. Trouble is we'd need to
  do this for all fences in the entire system, and just the
  book-keeping for that will be fun. Plus lots of drivers use fences
  for all kinds of internal stuff like memory management, so
  unconditionally resetting all of them doesn't work.

  I'm also hoping that with these fence annotations we could enlist
  lockdep in finding the last offenders causing deadlocks, and we
  could remove this get-out-of-jail trick.

- The more feasible approach (across drivers at least as part of the
  dma_fence contract) is what drm/i915 does for gen2/3: When we need
  to reset the display we wake up all dma_fence_wait_interruptible
  calls, or well at least the equivalent of those in i915 internally.

  Relying on ioctl restart we force all other threads to release their
  locks, which means the tdr thread is guaranteed to be able to get
  them. I think we could implement this at the dma_fence level,
  including proper lockdep annotations.

  dma_fence_begin_tdr():
  - must be nested within a dma_fence_begin/end_signalling section
  - will wake up all interruptible (but not the non-interruptible)
dma_fence_wait() calls and force them to complete with a
-ERESTARTSYS errno code. All new interrupitble calls to
dma_fence_wait() will immeidately fail with the same error code.

  dma_fence_end_trdr():
  - this will convert dma_fence_wait() calls back to normal.

  Of course interrupting dma_fence_wait is only ok if the caller
  specified that, which means we need to split the annotations into
  interruptible and non-interruptible version. If we then make sure
  that we only use interruptible dma_fence_wait() calls while holding
  drm_modeset_lock we can grab them in tdr code, and allow display
  resets. Doing the same for dma_resv_lock might be a lot harder, so
  buffer updates must be avoided.

  What's worse, we're not going to be able to make the dma_fence_wait
  calls in mmu-notifiers interruptible, that doesn't work. So
  allocating memory still wont' be allowed, even in tdr sections. Plus
  obviously we can use this trick only in tdr, it is rather intrusive.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/scheduler/sched_main.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index f69abc4e70d3..ae0d5ceca49a 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -281,9 +281,12 @@ static void drm_sched_job_timedout(struct work_struct 
*work)
 {
struct drm_gpu_scheduler *sched;
struct drm_sched_job *job;
+   bool fence_cookie;
 
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
 
+   fence_cookie = dma_fence_begin_signalling();
+
/* Protects against concurrent deletion in drm_sched_get_cleanup_job */
spin_lock(&sched->job_list_lock);
job = list_first_entry_or_null(&sched->ring_mirror_list,
@@ -315,6 +318,8 @@ static void drm_sched_job_timedout(struct work_struct *work)
spin_lock(&sched->job_list_lock);
drm_sched_start_timeout(sched);
spin_unlock(&sched->job_list_lock);
+
+   dma_fence_end_signalling(fence_cookie);
 }
 
  /**
-- 
2.28.0

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

[PATCH 22/65] Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset"

2020-10-23 Thread Daniel Vetter 
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!

This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.

It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be held when we allocate memory, which
might never happen because the dma_fence_wait() is stuck waiting on
our gpu reset:

[  136.763714] ==
[  136.763714] WARNING: possible circular locking dependency detected
[  136.763715] 5.7.0-rc3+ #346 Tainted: GW
[  136.763716] --
[  136.763716] kworker/2:3/682 is trying to acquire lock:
[  136.763716] 8226f140 (console_lock){+.+.}-{0:0}, at: 
drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[  136.763723]
   but task is already holding lock:
[  136.763724] 82318c80 (dma_fence_map){}-{0:0}, at: 
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[  136.763726]
   which lock already depends on the new lock.

[  136.763726]
   the existing dependency chain (in reverse order) is:
[  136.763727]
   -> #2 (dma_fence_map){}-{0:0}:
[  136.763730]__dma_fence_might_wait+0x41/0xb0
[  136.763732]dma_resv_lockdep+0x171/0x202
[  136.763734]do_one_initcall+0x5d/0x2f0
[  136.763736]kernel_init_freeable+0x20d/0x26d
[  136.763738]kernel_init+0xa/0xfb
[  136.763740]ret_from_fork+0x27/0x50
[  136.763740]
   -> #1 (fs_reclaim){+.+.}-{0:0}:
[  136.763743]fs_reclaim_acquire.part.0+0x25/0x30
[  136.763745]kmem_cache_alloc_trace+0x2e/0x6e0
[  136.763747]device_create_groups_vargs+0x52/0xf0
[  136.763747]device_create+0x49/0x60
[  136.763749]fb_console_init+0x25/0x145
[  136.763750]fbmem_init+0xcc/0xe2
[  136.763750]do_one_initcall+0x5d/0x2f0
[  136.763751]kernel_init_freeable+0x20d/0x26d
[  136.763752]kernel_init+0xa/0xfb
[  136.763753]ret_from_fork+0x27/0x50
[  136.763753]
   -> #0 (console_lock){+.+.}-{0:0}:
[  136.763755]__lock_acquire+0x1241/0x23f0
[  136.763756]lock_acquire+0xad/0x370
[  136.763757]console_lock+0x47/0x70
[  136.763761]drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 
[drm_kms_helper]
[  136.763809]amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[  136.763850]amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[  136.763851]drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[  136.763852]process_one_work+0x23c/0x580
[  136.763853]worker_thread+0x50/0x3b0
[  136.763854]kthread+0x12e/0x150
[  136.763855]ret_from_fork+0x27/0x50
[  136.763855]
   other info that might help us debug this:

[  136.763856] Chain exists of:
 console_lock --> fs_reclaim --> dma_fence_map

[  136.763857]  Possible unsafe locking scenario:

[  136.763857]CPU0CPU1
[  136.763857]
[  136.763857]   lock(dma_fence_map);
[  136.763858]lock(fs_reclaim);
[  136.763858]lock(dma_fence_map);
[  136.763858]   lock(console_lock);
[  136.763859]
*** DEADLOCK ***

[  136.763860] 4 locks held by kworker/2:3/682:
[  136.763860]  #0: 8887fb81c938 ((wq_completion)events){+.+.}-{0:0}, at: 
process_one_work+0x1bc/0x580
[  136.763862]  #1: c9cafe58 
((work_completion)(&(&sched->work_tdr)->work)){+.+.}-{0:0}, at: 
process_one_work+0x1bc/0x580
[  136.763863]  #2: 82318c80 (dma_fence_map){}-{0:0}, at: 
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[  136.763865]  #3: 8887ab621748 (&adev->lock_reset){+.+.}-{3:3}, at: 
amdgpu_device_gpu_recover.cold+0x5ab/0xe7b [amdgpu]
[  136.763914]
   stack backtrace:
[  136.763915] CPU: 2 PID: 682 Comm: kworker/2:3 Tainted: GW 
5.7.0-rc3+ #346
[  136.763916] Hardware name: System manufacturer System Product Name/PRIME 
X370-PRO, BIOS 4011 04/19/2018
[  136.763918] Workqueue: events drm_sched_job_timedout [gpu_sched]
[  136.763919] Call Trace:
[  136.763922]  dump_stack+0x8f/0xd0
[  136.763924]  check_noncircular+0x162/0x180
[  136.763926]  __lock_acquire+0x1241/0x23f0
[  136.763927]  lock_acquire+0xad/0x370
[  136.763932]  ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[  136.763933]  ? mark_held_locks+0x2d/0x80
[  136.763934]  ? _raw_spin_unlock_irqrestore+0x46/0x60
[  136.763936]  console_lock+0x47/0x70
[  136.763940]  ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[  136.763944]  drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[  136.763993]  amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[  136.764036]  amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[  136.764038]  drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[  136.764

[PATCH 23/65] drm/i915: Annotate dma_fence_work

2020-10-23 Thread Daniel Vetter 
i915 does tons of allocations from this worker, which lockdep catches.

Also generic infrastructure like this with big potential for how
dma_fence or other cross driver contracts work, really should be
reviewed on dri-devel. Implementing custom wheels for everything
within the driver is a classic case of "platform problem" [1]. Which in
upstream we really shouldn't have.

Since there's no quick way to solve these splats (dma_fence_work is
used a bunch in basic buffer management and command submission) like
for amdgpu, I'm giving up at this point here. Annotating i915
scheduler and gpu reset could would be interesting, but since lockdep
is one-shot we can't see what surprises would lurk there.

1: https://lwn.net/Articles/443531/
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_sw_fence_work.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c 
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index a3a81bb8f2c3..5b74acadaef5 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -17,12 +17,15 @@ static void fence_work(struct work_struct *work)
 {
struct dma_fence_work *f = container_of(work, typeof(*f), work);
int err;
+   bool fence_cookie;
 
+   fence_cookie = dma_fence_begin_signalling();
err = f->ops->work(f);
if (err)
dma_fence_set_error(&f->dma, err);
 
fence_complete(f);
+   dma_fence_end_signalling(fence_cookie);
dma_fence_put(&f->dma);
 }
 
-- 
2.28.0

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

[PATCH 21/65] drm/amdgpu: use dma-fence annotations for gpu reset code

2020-10-23 Thread Daniel Vetter 
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.

Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e8b41756c9f9..029a026ecfa9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4496,6 +4496,9 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
int i, r = 0;
bool need_emergency_restart = false;
bool audio_suspended = false;
+   bool fence_cookie;
+
+   fence_cookie = dma_fence_begin_signalling();
 
/**
 * Special case: RAS triggered and full reset isn't supported
@@ -4529,6 +4532,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as 
another already in progress",
job ? job->base.id : -1, hive->hive_id);
amdgpu_put_xgmi_hive(hive);
+   dma_fence_end_signalling(fence_cookie);
return 0;
}
mutex_lock(&hive->hive_lock);
@@ -4541,8 +4545,10 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
 */
INIT_LIST_HEAD(&device_list);
if (adev->gmc.xgmi.num_physical_nodes > 1) {
-   if (!hive)
+   if (!hive) {
+   dma_fence_end_signalling(fence_cookie);
return -ENODEV;
+   }
if (!list_is_first(&adev->gmc.xgmi.head, &hive->device_list))
list_rotate_to_front(&adev->gmc.xgmi.head, 
&hive->device_list);
device_list_handle = &hive->device_list;
@@ -4556,8 +4562,6 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
if (!amdgpu_device_lock_adev(tmp_adev, hive)) {
dev_info(tmp_adev->dev, "Bailing on TDR for s_job:%llx, 
as another already in progress",
  job ? job->base.id : -1);
-   r = 0;
-   goto skip_recovery;
}
 
/*
@@ -4699,6 +4703,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
 
if (r)
dev_info(adev->dev, "GPU reset end with ret = %d\n", r);
+   dma_fence_end_signalling(fence_cookie);
return r;
 }
 
-- 
2.28.0

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

[PATCH 1/5] drm/radeon: Stop changing the drm_driver struct

2020-10-23 Thread Daniel Vetter 
With only the kms driver left, we can fold this in. This means
we need to move the ioctl table, which means one additional ioctl
must be defined in headers.

Also there's a conflict between the radeon_init macro and the module
init function, so rename the module functions to avoid that.

Signed-off-by: Daniel Vetter 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/radeon/radeon.h |  1 +
 drivers/gpu/drm/radeon/radeon_drv.c | 85 -
 drivers/gpu/drm/radeon/radeon_kms.c | 49 +
 3 files changed, 62 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5d54bccebd4d..f475785d6491 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2244,6 +2244,7 @@ int radeon_gem_set_tiling_ioctl(struct drm_device *dev, 
void *data,
struct drm_file *filp);
 int radeon_gem_get_tiling_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file 
*filp);
 
 /* VRAM scratch page for HDP bug, default vram page */
 struct r600_vram_scratch {
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 65061c949aee..9c11e36ad33a 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -51,6 +51,7 @@
 #include 
 
 #include "radeon_drv.h"
+#include "radeon.h"
 
 /*
  * KMS wrapper.
@@ -129,8 +130,6 @@ extern int radeon_get_crtc_scanoutpos(struct drm_device 
*dev, unsigned int crtc,
  ktime_t *stime, ktime_t *etime,
  const struct drm_display_mode *mode);
 extern bool radeon_is_px(struct drm_device *dev);
-extern const struct drm_ioctl_desc radeon_ioctls_kms[];
-extern int radeon_max_kms_ioctl;
 int radeon_mmap(struct file *filp, struct vm_area_struct *vma);
 int radeon_mode_dumb_mmap(struct drm_file *filp,
  struct drm_device *dev,
@@ -584,9 +583,55 @@ static const struct file_operations radeon_driver_kms_fops 
= {
 #endif
 };
 
+static const struct drm_ioctl_desc radeon_ioctls_kms[] = {
+   DRM_IOCTL_DEF_DRV(RADEON_CP_INIT, drm_invalid_op, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF_DRV(RADEON_CP_START, drm_invalid_op, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF_DRV(RADEON_CP_STOP, drm_invalid_op, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF_DRV(RADEON_CP_RESET, drm_invalid_op, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF_DRV(RADEON_CP_IDLE, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_CP_RESUME, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_RESET, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_FULLSCREEN, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_SWAP, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_CLEAR, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_VERTEX, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_INDICES, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_TEXTURE, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_STIPPLE, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_INDIRECT, drm_invalid_op, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF_DRV(RADEON_VERTEX2, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_CMDBUF, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_GETPARAM, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_FLIP, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_ALLOC, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_FREE, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_INIT_HEAP, drm_invalid_op, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF_DRV(RADEON_IRQ_EMIT, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_IRQ_WAIT, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_SETPARAM, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_SURF_ALLOC, drm_invalid_op, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_SURF_FREE, drm_invalid_op, DRM_AUTH),
+   /* KMS */
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_INFO, radeon_gem_info_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_CREATE, radeon_gem_create_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_PREAD, radeon_gem_pread_ioctl, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_PWRITE, radeon_gem_pwrite_ioctl, DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl, 
DRM_AUT

Re: [PATCH] drm/amdgpu: always reset asic when going into suspend

2020-10-23 Thread Alex Deucher 
On Thu, Jan 16, 2020 at 10:14 AM Alex Deucher  wrote:
>
> On Wed, Jan 15, 2020 at 2:44 AM Daniel Drake  wrote:
> >
> > On Thu, Dec 19, 2019 at 10:08 PM Alex Deucher  wrote:
> > > I think there may be some AMD specific handling needed in
> > > drivers/acpi/sleep.c.  My understanding from reading the modern
> > > standby documents from MS is that each vendor needs to provide a
> > > platform specific PEP driver.  I'm not sure how much of that current
> > > code is Intel specific or not.
> >
> > I don't think there is anything Intel-specific in drivers/acpi/sleep.c.
> >
> > Reading more about PEP, I see that Linux supports PEP devices with
> > ACPI ID INT33A1 or PNP0D80. Indeed the Intel platforms we work with
> > have INT33A1 devices in their ACPI tables.
> >
> > This product has a \_SB.PEP ACPI device with _HID AMD0004 and _CID
> > PNP0D80. Full acpidump:
> > https://gist.github.com/dsd/ff3dfc0f63cdd9eba4a0fbd9e776e8be (see
> > ssdt7)
> >
> > This PEP device responds to a _DSM with UUID argument
> > "e3f32452-febc-43ce-9039-932122d37721", which is not the one
> > documented at 
> > https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
> >
> > Nevertheless, there is some data about the GPU:
> > Package (0x04)
> > {
> > One,
> > "\\_SB.PCI0.GP17.VGA",
> > Zero,
> > 0x03
> > },
> >
> > However since this data is identical to many other devices that
> > suspend and resume just fine, I wonder if it is really important.
> >
> > The one supported method does offer two calls which may mirror the
> > Display Off/On Notifications in the above spec:
> > Case (0x02)
> > {
> > \_SB.PCI0.SBRG.EC0.CSEE (0xB7)
> > Return (Zero)
> > }
> > Case (0x03)
> > {
> > \_SB.PCI0.SBRG.EC0.CSEE (0xB8)
> > Notify (\_SB.PCI0.SBRG.EC0.LID, 0x80) //
> > Status Change
> > Return (Zero)
> > }
> >
> > but I tried executing this code after suspending amdgpu, and the
> > problem still stands, amdgpu cannot wakeup correctly.
> >
> > There's nothing else really interesting in the PEP device as far as I can 
> > see.
> >
> > PEP things aside, I am still quite suspicious about the fact that
> > calling amdgpu_device_suspend() then amdgpu_device_resume() on
> > multiple products (not just this one) fails. It seems that this code
> > flow is relying on the BIOS doing something in the S3 suspend/resume
> > path in order to make the device resumable by amdgpu_device_resume(),
> > which is why we have only encountered this issue for the first time on
> > our first AMD platform that does not support S3 suspend.
> >
>
> It makes sense.  This is an SOC, not a collection of individual
> devices.  There are more devices than power rails so the sbios (via
> ACPI) has to handle the power rail.  All of the devices using that
> power rail have to suspend and tell the sbios before the platform
> microcontroller can turn off the power rail.  Presumably there is
> something missing that prevents the microcontroller for powering down
> the rail.  If the power rail is kept on, the device is never powered
> off and still retains its current state.
>
> > With that in mind, and lacking any better info, wouldn't it make sense
> > for amdgpu_device_resume() to always call reset? Maybe it's not
> > necessary in the S3 case, but it shouldn't harm anything. Or perhaps
> > it could check if the device is alive and reset it if it's not?
>
> It's just papering over the problem.  It would be better from a power
> perspective for the driver to just not suspend and keep running like
> normal.  When the driver is not suspended runtime things like clock
> and power gating are active which keep the GPU power at a minimum.
>
> >
> > Alternatively do you have any other contacts within AMD that could
> > help us figure out the underlying question of how to correctly suspend
> > and resume these devices? Happy to ship an affected product sample
> > your way.
> >
>
> I talked to our sbios team and they seem to think our S0ix
> implementation works pretty differently from Intel's.  I'm not really
> an expert on this area however.  We have a new team ramping on up this
> for Linux however.

Initial patches for S0ix platform support:
https://patchwork.kernel.org/project/platform-driver-x86/patch/20201023080410.458629-1-shyam-sundar@amd.com/
https://patchwork.kernel.org/project/linux-acpi/patch/20201023080315.458570-1-shyam-sundar@amd.com/

You also need the following GPU driver patches:
https://patchwork.freedesktop.org/series/82762/

There is also an audio patch required which will be available soon.

Alex
__

[PATCH 1/3] drm/amdgpu: add mode2 reset support for vangogh

2020-10-23 Thread Alex Deucher 
GPU reset is handled via SMU similar to previous APUs.

Acked-by: Evan Quan 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
index 145712a24b80..ec40117aa1c0 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
@@ -322,6 +322,11 @@ static bool vangogh_is_dpm_running(struct smu_context *smu)
 
 }
 
+static int vangogh_mode2_reset(struct smu_context *smu)
+{
+   return smu_cmn_send_smc_msg_with_param(smu, 
SMU_MSG_GfxDeviceDriverReset, SMU_RESET_MODE_2, NULL);
+}
+
 static const struct pptable_funcs vangogh_ppt_funcs = {
.dpm_set_vcn_enable = vangogh_dpm_set_vcn_enable,
.dpm_set_jpeg_enable = vangogh_dpm_set_jpeg_enable,
@@ -342,6 +347,7 @@ static const struct pptable_funcs vangogh_ppt_funcs = {
.set_pp_feature_mask = smu_cmn_set_pp_feature_mask,
.disable_all_features_with_exception = 
smu_cmn_disable_all_features_with_exception,
.interrupt_work = smu_v11_0_interrupt_work,
+   .mode2_reset = vangogh_mode2_reset,
 };
 
 void vangogh_set_ppt_funcs(struct smu_context *smu)
-- 
2.25.4

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

[PATCH 2/3] drm/amdgpu/nv: add mode2 reset handling

2020-10-23 Thread Alex Deucher 
Vangogh will use mode2 reset, so plumb it through the nv
soc driver.

Acked-by: Evan Quan 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/nv.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 72435e0eb8b9..bf363841d0c8 100644
--- a/drivers/gpu/drm/amd/amdgpu/nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/nv.c
@@ -352,6 +352,7 @@ nv_asic_reset_method(struct amdgpu_device *adev)
struct smu_context *smu = &adev->smu;
 
if (amdgpu_reset_method == AMD_RESET_METHOD_MODE1 ||
+   amdgpu_reset_method == AMD_RESET_METHOD_MODE2 ||
amdgpu_reset_method == AMD_RESET_METHOD_BACO)
return amdgpu_reset_method;
 
@@ -360,6 +361,8 @@ nv_asic_reset_method(struct amdgpu_device *adev)
  amdgpu_reset_method);
 
switch (adev->asic_type) {
+   case CHIP_VANGOGH:
+   return AMD_RESET_METHOD_MODE2;
case CHIP_SIENNA_CICHLID:
case CHIP_NAVY_FLOUNDER:
return AMD_RESET_METHOD_MODE1;
@@ -376,7 +379,8 @@ static int nv_asic_reset(struct amdgpu_device *adev)
int ret = 0;
struct smu_context *smu = &adev->smu;
 
-   if (nv_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) {
+   switch (nv_asic_reset_method(adev)) {
+   case AMD_RESET_METHOD_BACO:
dev_info(adev->dev, "BACO reset\n");
 
ret = smu_baco_enter(smu);
@@ -385,9 +389,15 @@ static int nv_asic_reset(struct amdgpu_device *adev)
ret = smu_baco_exit(smu);
if (ret)
return ret;
-   } else {
+   break;
+   case AMD_RESET_METHOD_MODE2:
+   dev_info(adev->dev, "MODE2 reset\n");
+   ret = amdgpu_dpm_mode2_reset(adev);
+   break;
+   default:
dev_info(adev->dev, "MODE1 reset\n");
ret = nv_asic_mode1_reset(adev);
+   break;
}
 
return ret;
-- 
2.25.4

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

[PATCH 3/3] drm/amdgpu: Enable GPU reset for vangogh

2020-10-23 Thread Alex Deucher 
Enable GPU reset when we encounter a hang.

Acked-by: Evan Quan 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a7c95b3205ef..0601509f4262 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4178,6 +4178,7 @@ bool amdgpu_device_should_recover_gpu(struct 
amdgpu_device *adev)
case CHIP_NAVI14:
case CHIP_NAVI12:
case CHIP_SIENNA_CICHLID:
+   case CHIP_VANGOGH:
break;
default:
goto disabled;
-- 
2.25.4

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

[PATCH v3 03/56] amdgpu: fix a few kernel-doc markup issues

2020-10-23 Thread Mauro Carvalho Chehab 
A kernel-doc markup can't be mixed with a random comment,
as it causes parsing problems.

While here, change an invalid kernel-doc markup into
a common comment.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f8785bdec79c..1d4b54950528 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -239,9 +239,11 @@ bool amdgpu_device_supports_baco(struct drm_device *dev)
return amdgpu_asic_supports_baco(adev);
 }
 
+/*
+ * VRAM access helper functions
+ */
+
 /**
- * VRAM access helper functions.
- *
  * amdgpu_device_vram_access - read/write a buffer in vram
  *
  * @adev: amdgpu_device pointer
@@ -4497,7 +4499,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
bool need_emergency_restart = false;
bool audio_suspended = false;
 
-   /**
+   /*
 * Special case: RAS triggered and full reset isn't supported
 */
need_emergency_restart = amdgpu_ras_need_emergency_restart(adev);
-- 
2.26.2

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

[PATCH v3 02/56] drm: amdgpu_dm: fix a typo

2020-10-23 Thread Mauro Carvalho Chehab 
dm_comressor_info -> dm_compressor_info

The kernel-doc markup is right, but the struct itself
and their references contain a typo.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 6 +++---
 2 files changed, 4 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 bb1bc7f5d149..48ec0535d92f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -583,7 +583,7 @@ static void amdgpu_dm_fbc_init(struct drm_connector 
*connector)
 {
struct drm_device *dev = connector->dev;
struct amdgpu_device *adev = drm_to_adev(dev);
-   struct dm_comressor_info *compressor = &adev->dm.compressor;
+   struct dm_compressor_info *compressor = &adev->dm.compressor;
struct amdgpu_dm_connector *aconn = to_amdgpu_dm_connector(connector);
struct drm_display_mode *mode;
unsigned long max_size = 0;
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 34f6369bf51f..a8a0e8cb1a11 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -86,7 +86,7 @@ struct irq_list_head {
  * @bo_ptr: Pointer to the buffer object
  * @gpu_addr: MMIO gpu addr
  */
-struct dm_comressor_info {
+struct dm_compressor_info {
void *cpu_addr;
struct amdgpu_bo *bo_ptr;
uint64_t gpu_addr;
@@ -148,7 +148,7 @@ struct amdgpu_dm_backlight_caps {
  * @soc_bounding_box: SOC bounding box values provided by gpu_info FW
  * @cached_state: Caches device atomic state for suspend/resume
  * @cached_dc_state: Cached state of content streams
- * @compressor: Frame buffer compression buffer. See &struct dm_comressor_info
+ * @compressor: Frame buffer compression buffer. See &struct dm_compressor_info
  * @force_timing_sync: set via debugfs. When set, indicates that all connected
  *displays will be forced to synchronize.
  */
@@ -324,7 +324,7 @@ struct amdgpu_display_manager {
struct drm_atomic_state *cached_state;
struct dc_state *cached_dc_state;
 
-   struct dm_comressor_info compressor;
+   struct dm_compressor_info compressor;
 
const struct firmware *fw_dmcu;
uint32_t dmcu_fw_version;
-- 
2.26.2

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

[PATCH v3 11/56] drm/amdgpu: fix some kernel-doc markups

2020-10-23 Thread Mauro Carvalho Chehab 
Some functions have different names between their prototypes
and the kernel-doc markup.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
 include/uapi/drm/amdgpu_drm.h| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index df110afa97bf..a5f73a267fe5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2166,7 +2166,7 @@ struct amdgpu_bo_va *amdgpu_vm_bo_add(struct 
amdgpu_device *adev,
 
 
 /**
- * amdgpu_vm_bo_insert_mapping - insert a new mapping
+ * amdgpu_vm_bo_insert_map - insert a new mapping
  *
  * @adev: amdgpu_device pointer
  * @bo_va: bo_va to store the address
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 0c6b7c5ecfec..795bad307497 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -528,7 +528,7 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
 }
 
 /**
- * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
+ * amdgpu_vram_mgr_free_sgt - allocate and fill a sg table
  *
  * @adev: amdgpu device pointer
  * @sgt: sg table to free
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index c5ff2b275fcd..791a1d597d2a 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -667,7 +667,7 @@ struct drm_amdgpu_cs_chunk_data {
};
 };
 
-/**
+/*
  *  Query h/w info: Flag that this is integrated (a.h.a. fusion) GPU
  *
  */
-- 
2.26.2

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

Re: [PATCH v3 03/56] amdgpu: fix a few kernel-doc markup issues

2020-10-23 Thread Christian König 

Am 23.10.20 um 18:32 schrieb Mauro Carvalho Chehab:

A kernel-doc markup can't be mixed with a random comment,
as it causes parsing problems.

While here, change an invalid kernel-doc markup into
a common comment.

Signed-off-by: Mauro Carvalho Chehab 


Acked-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f8785bdec79c..1d4b54950528 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -239,9 +239,11 @@ bool amdgpu_device_supports_baco(struct drm_device *dev)
return amdgpu_asic_supports_baco(adev);
  }
  
+/*

+ * VRAM access helper functions
+ */
+
  /**
- * VRAM access helper functions.
- *
   * amdgpu_device_vram_access - read/write a buffer in vram
   *
   * @adev: amdgpu_device pointer
@@ -4497,7 +4499,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
bool need_emergency_restart = false;
bool audio_suspended = false;
  
-	/**

+   /*
 * Special case: RAS triggered and full reset isn't supported
 */
need_emergency_restart = amdgpu_ras_need_emergency_restart(adev);


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

Re: [PATCH v3 11/56] drm/amdgpu: fix some kernel-doc markups

2020-10-23 Thread Christian König 

Am 23.10.20 um 18:32 schrieb Mauro Carvalho Chehab:

Some functions have different names between their prototypes
and the kernel-doc markup.

Signed-off-by: Mauro Carvalho Chehab 


Acked-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
  include/uapi/drm/amdgpu_drm.h| 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index df110afa97bf..a5f73a267fe5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2166,7 +2166,7 @@ struct amdgpu_bo_va *amdgpu_vm_bo_add(struct 
amdgpu_device *adev,
  
  
  /**

- * amdgpu_vm_bo_insert_mapping - insert a new mapping
+ * amdgpu_vm_bo_insert_map - insert a new mapping
   *
   * @adev: amdgpu_device pointer
   * @bo_va: bo_va to store the address
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 0c6b7c5ecfec..795bad307497 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -528,7 +528,7 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
  }
  
  /**

- * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
+ * amdgpu_vram_mgr_free_sgt - allocate and fill a sg table
   *
   * @adev: amdgpu device pointer
   * @sgt: sg table to free
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index c5ff2b275fcd..791a1d597d2a 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -667,7 +667,7 @@ struct drm_amdgpu_cs_chunk_data {
};
  };
  
-/**

+/*
   *  Query h/w info: Flag that this is integrated (a.h.a. fusion) GPU
   *
   */


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

[PATCH] drm/amd/display: Fixed panic during seamless boot.

2020-10-23 Thread Aurabindo Pillai 
From: David Galiffi 

[why]
get_pixel_clk_frequency_100hz is undefined in clock_source_funcs.

[how]
set function pointer: ".get_pixel_clk_frequency_100hz = 
get_pixel_clk_frequency_100hz"

Signed-off-by: David Galiffi 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
index 512b26b3e3fd..589c7fb71480 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
@@ -1149,7 +1149,8 @@ static uint32_t dcn3_get_pix_clk_dividers(
 static const struct clock_source_funcs dcn3_clk_src_funcs = {
.cs_power_down = dce110_clock_source_power_down,
.program_pix_clk = dcn3_program_pix_clk,
-   .get_pix_clk_dividers = dcn3_get_pix_clk_dividers
+   .get_pix_clk_dividers = dcn3_get_pix_clk_dividers,
+   .get_pixel_clk_frequency_100hz = get_pixel_clk_frequency_100hz
 };
 #endif
 /*/
-- 
2.25.1

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

Re: [PATCH v3 03/56] amdgpu: fix a few kernel-doc markup issues

2020-10-23 Thread Alex Deucher 
Applied.  Thanks!

Alex

On Fri, Oct 23, 2020 at 12:38 PM Christian König
 wrote:
>
> Am 23.10.20 um 18:32 schrieb Mauro Carvalho Chehab:
> > A kernel-doc markup can't be mixed with a random comment,
> > as it causes parsing problems.
> >
> > While here, change an invalid kernel-doc markup into
> > a common comment.
> >
> > Signed-off-by: Mauro Carvalho Chehab 
>
> Acked-by: Christian König 
>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 +---
> >   1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index f8785bdec79c..1d4b54950528 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -239,9 +239,11 @@ bool amdgpu_device_supports_baco(struct drm_device 
> > *dev)
> >   return amdgpu_asic_supports_baco(adev);
> >   }
> >
> > +/*
> > + * VRAM access helper functions
> > + */
> > +
> >   /**
> > - * VRAM access helper functions.
> > - *
> >* amdgpu_device_vram_access - read/write a buffer in vram
> >*
> >* @adev: amdgpu_device pointer
> > @@ -4497,7 +4499,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device 
> > *adev,
> >   bool need_emergency_restart = false;
> >   bool audio_suspended = false;
> >
> > - /**
> > + /*
> >* Special case: RAS triggered and full reset isn't supported
> >*/
> >   need_emergency_restart = amdgpu_ras_need_emergency_restart(adev);
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 11/56] drm/amdgpu: fix some kernel-doc markups

2020-10-23 Thread Alex Deucher 
Applied.  Thanks!

Alex

On Fri, Oct 23, 2020 at 12:51 PM Christian König
 wrote:
>
> Am 23.10.20 um 18:32 schrieb Mauro Carvalho Chehab:
> > Some functions have different names between their prototypes
> > and the kernel-doc markup.
> >
> > Signed-off-by: Mauro Carvalho Chehab 
>
> Acked-by: Christian König 
>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
> >   include/uapi/drm/amdgpu_drm.h| 2 +-
> >   3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > index df110afa97bf..a5f73a267fe5 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > @@ -2166,7 +2166,7 @@ struct amdgpu_bo_va *amdgpu_vm_bo_add(struct 
> > amdgpu_device *adev,
> >
> >
> >   /**
> > - * amdgpu_vm_bo_insert_mapping - insert a new mapping
> > + * amdgpu_vm_bo_insert_map - insert a new mapping
> >*
> >* @adev: amdgpu_device pointer
> >* @bo_va: bo_va to store the address
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > index 0c6b7c5ecfec..795bad307497 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > @@ -528,7 +528,7 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device 
> > *adev,
> >   }
> >
> >   /**
> > - * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
> > + * amdgpu_vram_mgr_free_sgt - allocate and fill a sg table
> >*
> >* @adev: amdgpu device pointer
> >* @sgt: sg table to free
> > diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
> > index c5ff2b275fcd..791a1d597d2a 100644
> > --- a/include/uapi/drm/amdgpu_drm.h
> > +++ b/include/uapi/drm/amdgpu_drm.h
> > @@ -667,7 +667,7 @@ struct drm_amdgpu_cs_chunk_data {
> >   };
> >   };
> >
> > -/**
> > +/*
> >*  Query h/w info: Flag that this is integrated (a.h.a. fusion) GPU
> >*
> >*/
>
> ___
> 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 v3 02/56] drm: amdgpu_dm: fix a typo

2020-10-23 Thread Alex Deucher 
Applied.  Thanks!

Alex

On Fri, Oct 23, 2020 at 12:33 PM Mauro Carvalho Chehab
 wrote:
>
> dm_comressor_info -> dm_compressor_info
>
> The kernel-doc markup is right, but the struct itself
> and their references contain a typo.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 6 +++---
>  2 files changed, 4 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 bb1bc7f5d149..48ec0535d92f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -583,7 +583,7 @@ static void amdgpu_dm_fbc_init(struct drm_connector 
> *connector)
>  {
> struct drm_device *dev = connector->dev;
> struct amdgpu_device *adev = drm_to_adev(dev);
> -   struct dm_comressor_info *compressor = &adev->dm.compressor;
> +   struct dm_compressor_info *compressor = &adev->dm.compressor;
> struct amdgpu_dm_connector *aconn = to_amdgpu_dm_connector(connector);
> struct drm_display_mode *mode;
> unsigned long max_size = 0;
> 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 34f6369bf51f..a8a0e8cb1a11 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -86,7 +86,7 @@ struct irq_list_head {
>   * @bo_ptr: Pointer to the buffer object
>   * @gpu_addr: MMIO gpu addr
>   */
> -struct dm_comressor_info {
> +struct dm_compressor_info {
> void *cpu_addr;
> struct amdgpu_bo *bo_ptr;
> uint64_t gpu_addr;
> @@ -148,7 +148,7 @@ struct amdgpu_dm_backlight_caps {
>   * @soc_bounding_box: SOC bounding box values provided by gpu_info FW
>   * @cached_state: Caches device atomic state for suspend/resume
>   * @cached_dc_state: Cached state of content streams
> - * @compressor: Frame buffer compression buffer. See &struct 
> dm_comressor_info
> + * @compressor: Frame buffer compression buffer. See &struct 
> dm_compressor_info
>   * @force_timing_sync: set via debugfs. When set, indicates that all 
> connected
>   *displays will be forced to synchronize.
>   */
> @@ -324,7 +324,7 @@ struct amdgpu_display_manager {
> struct drm_atomic_state *cached_state;
> struct dc_state *cached_dc_state;
>
> -   struct dm_comressor_info compressor;
> +   struct dm_compressor_info compressor;
>
> const struct firmware *fw_dmcu;
> uint32_t dmcu_fw_version;
> --
> 2.26.2
>
> ___
> 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: Fixed panic during seamless boot.

2020-10-23 Thread Lakha, Bhawanpreet 
[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Bhawanpreet Lakha 

From: Aurabindo Pillai 
Sent: October 23, 2020 1:09 PM
To: amd-gfx@lists.freedesktop.org 
Cc: Lakha, Bhawanpreet ; Galiffi, David 

Subject: [PATCH] drm/amd/display: Fixed panic during seamless boot.

From: David Galiffi 

[why]
get_pixel_clk_frequency_100hz is undefined in clock_source_funcs.

[how]
set function pointer: ".get_pixel_clk_frequency_100hz = 
get_pixel_clk_frequency_100hz"

Signed-off-by: David Galiffi 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
index 512b26b3e3fd..589c7fb71480 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
@@ -1149,7 +1149,8 @@ static uint32_t dcn3_get_pix_clk_dividers(
 static const struct clock_source_funcs dcn3_clk_src_funcs = {
 .cs_power_down = dce110_clock_source_power_down,
 .program_pix_clk = dcn3_program_pix_clk,
-   .get_pix_clk_dividers = dcn3_get_pix_clk_dividers
+   .get_pix_clk_dividers = dcn3_get_pix_clk_dividers,
+   .get_pixel_clk_frequency_100hz = get_pixel_clk_frequency_100hz
 };
 #endif
 /*/
--
2.25.1

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

Re: [PATCH] drm/amd/display: Fixed panic during seamless boot.

2020-10-23 Thread Aurabindo Pillai 
> [AMD Official Use Only - Internal Distribution Only]
> 
> 
> 
> 
> 
> 
> 
> Reviewed-by: Bhawanpreet Lakha 

Thanks for the review.
> 
> 
> 
> 
> From: Aurabindo Pillai 
> 
> Sent: October 23, 2020 1:09 PM
> 
> To: amd-gfx@lists.freedesktop.org 
> 
> Cc: Lakha, Bhawanpreet ; Galiffi, David <
> david.gali...@amd.com>
> 
> Subject: [PATCH] drm/amd/display: Fixed panic during seamless boot.
>  
> 
> 
> 
> From: David Galiffi 
> 
> 
> 
> [why]
> 
> get_pixel_clk_frequency_100hz is undefined in clock_source_funcs.
> 
> 
> 
> [how]
> 
> set function pointer: ".get_pixel_clk_frequency_100hz =
> get_pixel_clk_frequency_100hz"
> 
> 
> 
> Signed-off-by: David Galiffi 
> 
> ---
> 
>  drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
> 
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> 
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> 
> index 512b26b3e3fd..589c7fb71480 100644
> 
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> 
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> 
> @@ -1149,7 +1149,8 @@ static uint32_t dcn3_get_pix_clk_dividers(
> 
>  static const struct clock_source_funcs dcn3_clk_src_funcs = {
> 
>  .cs_power_down = dce110_clock_source_power_down,
> 
>  .program_pix_clk = dcn3_program_pix_clk,
> 
> -   .get_pix_clk_dividers = dcn3_get_pix_clk_dividers
> 
> +   .get_pix_clk_dividers = dcn3_get_pix_clk_dividers,
> 
> +   .get_pixel_clk_frequency_100hz =
> get_pixel_clk_frequency_100hz
> 
>  };
> 
>  #endif
> 
>  /*/
> 




signature.asc
Description: This is a digitally signed message part
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 0/3] drm/amd/display: Fix kernel panic by breakpoint

2020-10-23 Thread Luben Tuikov 
On 2020-10-23 03:46, Takashi Iwai wrote:
> Hi,
> 
> the amdgpu driver's ASSERT_CRITICAL() macro calls the
> kgdb_breakpoing() even if no debug option is set, and this leads to a
> kernel panic on distro kernels.  The first two patches are the
> oneliner fixes for those, while the last one is the cleanup of those
> debug macros.

This looks like good work and solid. Hopefully it gets picked up.

Regards,
Luben

> 
> 
> Takashi
> 
> ===
> 
> Takashi Iwai (3):
>   drm/amd/display: Fix kernel panic by dal_gpio_open() error
>   drm/amd/display: Don't invoke kgdb_breakpoint() unconditionally
>   drm/amd/display: Clean up debug macros
> 
>  drivers/gpu/drm/amd/display/Kconfig |  1 +
>  drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c |  4 +--
>  drivers/gpu/drm/amd/display/dc/os_types.h   | 33 
> +
>  3 files changed, 15 insertions(+), 23 deletions(-)
> 

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

Re: [PATCH] drm/amdgpu: Fix size calculation when init onchip memory

2020-10-23 Thread Luben Tuikov 
On 2020-10-23 03:12, Christian König wrote:
> Am 23.10.20 um 07:41 schrieb xinhui pan:
>> Size is page count here.
>>
>> Signed-off-by: xinhui pan 
> 
> Ah yes that one again. At some point we really need to clean that up.
> 
> Patch is Reviewed-by: Christian König 
> 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> index 4a85f8cedd77..11dd3d9eac15 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> @@ -65,11 +65,11 @@
>>   
>>   static int amdgpu_ttm_init_on_chip(struct amdgpu_device *adev,
>>  unsigned int type,
>> -uint64_t size)
>> +uint64_t size_in_page)
>>   {
>>  return ttm_range_man_init(&adev->mman.bdev, type,
>>TTM_PL_FLAG_UNCACHED, TTM_PL_FLAG_UNCACHED,
>> -  false, size >> PAGE_SHIFT);
>> +  false, size_in_page);

Why don't we call this "page_count" or "num_pages"?
"size_in_page" is really confusing and not something people
say and use in English.

Regards,
Luben

>>   }
>>   
>>   /**
> 
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cluben.tuikov%40amd.com%7C868c9232cb924441c02308d8772307e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637390339646490801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=H5r9C%2Bj3zVEsGSDNUlxl1%2Bg7lytcsczO7KpSymIv%2F0E%3D&reserved=0
> 

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