Re: [RFC PATCH 2/4] drm/scheduler: implement a function to modify sched list

[Christian König]

Am 28.02.20 um 06:08 schrieb Luben Tuikov:

On 2020-02-27 4:40 p.m., Nirmoy Das wrote:

implement drm_sched_entity_modify_sched() which can modify existing
sched_list with a different one. This is going to be helpful when
userspace changes priority of a ctx/entity then driver can switch to
corresponding hw shced list for that priority

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/scheduler/sched_entity.c | 24 
  include/drm/gpu_scheduler.h  |  4 
  2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
b/drivers/gpu/drm/scheduler/sched_entity.c
index 63bccd201b97..711e9d504bcb 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -83,6 +83,30 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
  }
  EXPORT_SYMBOL(drm_sched_entity_init);
  
+/**

+ * drm_sched_entity_modify_sched - Modify sched of an entity
+ *
+ * @entity: scheduler entity to init
+ * @sched_list: the list of new drm scheds which will replace
+ * existing entity->sched_list
+ * @num_sched_list: number of drm sched in sched_list
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
+ struct drm_gpu_scheduler **sched_list,
+ unsigned int num_sched_list)
+{
+   if (!(entity && sched_list && (num_sched_list == 0 || sched_list[0])))
+   return -EINVAL;

This seems unmaintainable. I'd write it in its natural form:


This is probably just copy & pasted from the init function and complete 
overkill here.




int drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
  struct drm_gpu_scheduler **sched_list,
  unsigned int num_sched_list)
{
if (entity && sched_list && (num_sched_list == 0 || sched_list[0] != 
NULL)) {
entity->sched_list = num_sched_list > 1 ? sched_list : NULL;
entity->num_sched_list = num_sched_list;
return 0;
} else {
return -EINVAL;
}
}


Actually that's a rather bad idea. Error handling should always be in 
the form of:


if (check_error || missing_prerequisite)
    return_or_goto_cleanup;


That's too heavy. Can we improve the architecture
so we don't have to check for this in leaf functions like this one?
We can just return a parameterization.

Why would this be called with entity being NULL?
Or with sched_list being NULL? Or num_sched_list being not zero
yet sched_list[0] being NULL? Why not make sure that sched_list[0] is
never NULL and that num_sched_list is greater than 0 always?

Does this make it to user space?
Why would the state of execution be one such that this is true/false
for the code to return -EINVAL?
 From patch 3/4 it seems that an error is printed inside 
amdgpu_ctx_priority_override()
and the result is not propagated up the stack.

I think we should improve the code where here this condition above
is never true. Then we can use parameterization for those two
statements below:


+
+   entity->sched_list = num_sched_list > 1 ? sched_list : NULL;

So if we're here, we know from the top conditional that
either num_sched_list is 0 or that sched_list[0] not NULL
or both.

So if num_sched_list is 0 or 1 we return NULL?
And if num_sched_list is 2 or greater we return sched_list
of which sched_list[0] could be NULL?


This is also copy from the init code and completely wrong here.

What we should do instead is just: WARN_ON(!num_sched_list || !sched_list);

And to the checking for not keeping around the scheduler list in the 
init function.



Why not fix the architecture so that this is simply copied?


We had that and moved away from it because the scheduler list is 
actually const and shouldn't be allocated with each entity (which we can 
easily have thousands of).


Regards,
Christian.


  (in which case
we can simply index-parameterize it and simply copy it.
Why are there so many checks everywhere?


+   entity->num_sched_list = num_sched_list;
+

I mean, all we're doing in this function is initializing
entity->sched_list and entity->num_sched_list. Why does this
function have to be so complex and do so many checks?
Can we improve/fix the architecture instead?

Regards,
Luben



+   return 0;
+}
+EXPORT_SYMBOL(drm_sched_entity_modify_sched);
+
  /**
   * drm_sched_entity_is_idle - Check if entity is idle
   *
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 589be851f8a1..0c164a96d51b 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -297,6 +297,10 @@ void drm_sched_fini(struct drm_gpu_scheduler *sched);
  int drm_sched_job_init(struct drm_sched_job *job,
   struct drm_sched_entity *entity,
   void *owner);
+int 

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Daniel Vetter]

On Fri, Feb 28, 2020 at 4:38 AM Dave Airlie  wrote:
>
> On Fri, 28 Feb 2020 at 07:27, Daniel Vetter  wrote:
> >
> > Hi all,
> >
> > You might have read the short take in the X.org board meeting minutes
> > already, here's the long version.
> >
> > The good news: gitlab.fd.o has become very popular with our
> > communities, and is used extensively. This especially includes all the
> > CI integration. Modern development process and tooling, yay!
> >
> > The bad news: The cost in growth has also been tremendous, and it's
> > breaking our bank account. With reasonable estimates for continued
> > growth we're expecting hosting expenses totalling 75k USD this year,
> > and 90k USD next year. With the current sponsors we've set up we can't
> > sustain that. We estimate that hosting expenses for gitlab.fd.o
> > without any of the CI features enabled would total 30k USD, which is
> > within X.org's ability to support through various sponsorships, mostly
> > through XDC.
> >
> > Note that X.org does no longer sponsor any CI runners themselves,
> > we've stopped that. The huge additional expenses are all just in
> > storing and serving build artifacts and images to outside CI runners
> > sponsored by various companies. A related topic is that with the
> > growth in fd.o it's becoming infeasible to maintain it all on
> > volunteer admin time. X.org is therefore also looking for admin
> > sponsorship, at least medium term.
> >
> > Assuming that we want cash flow reserves for one year of gitlab.fd.o
> > (without CI support) and a trimmed XDC and assuming no sponsor payment
> > meanwhile, we'd have to cut CI services somewhere between May and June
> > this year. The board is of course working on acquiring sponsors, but
> > filling a shortfall of this magnitude is neither easy nor quick work,
> > and we therefore decided to give an early warning as soon as possible.
> > Any help in finding sponsors for fd.o is very much appreciated.
>
> a) Ouch.
>
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor way from these
> hosting credits being bought by us, and I assume we aren't getting any
> sort of discounts here. Having google sponsor the credits costs google
> substantially less than having any other company give us money to do
> it.
>
> If our current CI architecture is going to burn this amount of money a
> year and we hadn't worked this out in advance of deploying it then I
> suggest the system should be taken offline until we work out what a
> sustainable system would look like within the budget we have, whether
> that be never transferring containers and build artifacts from the
> google network, just having local runner/build combos etc.

Google has sponsored 30k in hosting credits last year, these simply
ran out _much_ faster than anyone planned for. So this is by far not a
free thing for them. Plus there's also other companies sponsoring CI
runners and what not else in equally substantial amounts, plus the
biggest thing, sponsored admin time (more or less officially). So
there's a _lot_ of room for companies like Red Hat to sponsor without
throwing any money in google's revenue stream.

Or it doesn't happen, and then yeah the decision has already been made
to shutter the CI services. So this is also a question of whether we
(as a community and all the companies benefitting from the work done)
really want this, or maybe not quite.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC PATCH 1/3] drm/amdgpu: implement ring init_priority for compute ring

[Christian König]

Am 28.02.20 um 04:29 schrieb Luben Tuikov:

On 2020-02-26 3:37 p.m., Nirmoy Das wrote:

init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high 
priority
and 1st queue to normal priority.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 ++
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 +
  3 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 24caff085d00..a109373b9fe8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -170,6 +170,7 @@ struct amdgpu_ring_funcs {
/* priority functions */
void (*set_priority) (struct amdgpu_ring *ring,
  enum drm_sched_priority priority);
+   void (*init_priority) (struct amdgpu_ring *ring);
/* Try to soft recover the ring to make the fence signal */
void (*soft_recovery)(struct amdgpu_ring *ring, unsigned vmid);
int (*preempt_ib)(struct amdgpu_ring *ring);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index fa245973de12..14bab6e08bd6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -6334,6 +6334,19 @@ static void gfx_v8_0_ring_set_priority_compute(struct 
amdgpu_ring *ring,
gfx_v8_0_pipe_reserve_resources(adev, ring, acquire);
  }

+static void gfx_v8_0_ring_init_priority_compute(struct amdgpu_ring *ring)

Why two verbs in this function: "init" and "compute"?


Compute is not a verb here but rather the description of the ring type.


Certainly there is no need for "compute".
Just call it

gfx_blah_ring_priority_init()


I would call it gfx_*_init_compute_ring_priority().



Putting the object first and the verb last, as is commonly done.


We need to make sure that we note that this is for the compute rings.

Regards,
Christian.




+{
+   /* set pipe 0 to normal priority and pipe 1 to high priority*/
+   if (ring->queue == 1) {
+   gfx_v8_0_hqd_set_priority(ring->adev, ring, true);
+   gfx_v8_0_ring_set_pipe_percent(ring, true);
+   } else {
+   gfx_v8_0_hqd_set_priority(ring->adev, ring, false);
+   gfx_v8_0_ring_set_pipe_percent(ring, false);
+   }
+
+}

Again. Notice that the only difference between the two outcomes
of the conditional is the last parameter to both.

So you could write your code like this:

gfx_v8_0_hqd_set_priority(ring->adev, ring, ring->queue == 1);
gfx_v8_0_ring_set_pipe_percent(ring, ring->queue == 1);

Further more if "priority" had to be variable value,
I'd parameterize it in a map (i.e. array) and use
a computed index to index the map in order to retrieve
the variabled "priority". This eliminates if-conditionals.

Note in general that we want less if-conditionals,
in the execution path and more streamline execution.


+
  static void gfx_v8_0_ring_emit_fence_compute(struct amdgpu_ring *ring,
 u64 addr, u64 seq,
 unsigned flags)
@@ -6967,6 +6980,7 @@ static const struct amdgpu_ring_funcs 
gfx_v8_0_ring_funcs_compute = {
.insert_nop = amdgpu_ring_insert_nop,
.pad_ib = amdgpu_ring_generic_pad_ib,
.set_priority = gfx_v8_0_ring_set_priority_compute,
+   .init_priority = gfx_v8_0_ring_init_priority_compute,
.emit_wreg = gfx_v8_0_ring_emit_wreg,
  };

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 1c7a16b91686..0c66743fb6f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -5143,6 +5143,18 @@ static void gfx_v9_0_ring_set_priority_compute(struct 
amdgpu_ring *ring,
gfx_v9_0_pipe_reserve_resources(adev, ring, acquire);
  }

+static void gfx_v9_0_ring_init_priority_compute(struct amdgpu_ring *ring)

Ditto for this name as per above.


+{
+   /* set pipe 0 to normal priority and pipe 1 to high priority*/
+   if (ring->queue == 1) {
+   gfx_v9_0_hqd_set_priority(ring->adev, ring, true);
+   gfx_v9_0_ring_set_pipe_percent(ring, true);
+   } else {
+   gfx_v9_0_hqd_set_priority(ring->adev, ring, false);
+   gfx_v9_0_ring_set_pipe_percent(ring, true);
+   }
+}

Note how similar this is to the v8 above?
Those could be made the same and he vX parameterized to
the correct implementation.

For instance, if you parameterize the "gfx_vX_0_hqd_set_priority()"
and "gfx_vX_0_ring_set_pipe_percent()". Then your code becomes,
like this pseudo-code:

ring_init_set_priority(ring)
{
 map = ring->property[ring->version];

 map->hqd_priority_set(ring->adev, ring, ring->queue == 1);
 map->ring_pipe_percent_set(ring, ring->queue == 1);
}

Regards,
Luben



+
  static void 

[PATCH] drm/amdgpu: clean wptr on wb when gpu recovery

[Yintian Tao]

The TDR will be randomly failed due to compute ring
test failure. If the compute ring wptr & 0x7ff(ring_buf_mask)
is 0x100 then after map mqd the compute ring rptr will be
synced with 0x100. And the ring test packet size is also 0x100.
Then after invocation of amdgpu_ring_commit, the cp will not
really handle the packet on the ring buffer because rptr is equal to wptr.

Signed-off-by: Yintian Tao 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 44f00ecea322..5df1a6d45457 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -3508,6 +3508,7 @@ static int gfx_v10_0_kcq_init_queue(struct amdgpu_ring 
*ring)
 
/* reset ring buffer */
ring->wptr = 0;
+   atomic64_set((atomic64_t *)>wb.wb[ring->wptr_offs], 0);
amdgpu_ring_clear_ring(ring);
} else {
amdgpu_ring_clear_ring(ring);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 4135e4126e82..ac22490e8656 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -3664,6 +3664,7 @@ static int gfx_v9_0_kcq_init_queue(struct amdgpu_ring 
*ring)
 
/* reset ring buffer */
ring->wptr = 0;
+   atomic64_set((atomic64_t *)>wb.wb[ring->wptr_offs], 0);
amdgpu_ring_clear_ring(ring);
} else {
amdgpu_ring_clear_ring(ring);
-- 
2.17.1

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

RE: [PATCH] drm/amdgpu: Write blocked CP registers using RLC on VF

[Liu, Monk]

Reviewed-by: Monk Liu 

_
Monk Liu|GPU Virtualization Team |AMD


-Original Message-
From: amd-gfx  On Behalf Of Rohit Khaire
Sent: Wednesday, February 26, 2020 10:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Khaire, Rohit 
Subject: [PATCH] drm/amdgpu: Write blocked CP registers using RLC on VF

This change programs CP_ME_CNTL and RLC_CSIB_* through RLC

Signed-off-by: Rohit Khaire 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 44f00ecea322..8f99bc6163b7 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -1783,11 +1783,11 @@ static int gfx_v10_0_init_csb(struct amdgpu_device 
*adev)
adev->gfx.rlc.funcs->get_csb_buffer(adev, adev->gfx.rlc.cs_ptr);
 
/* csib */
-   WREG32_SOC15(GC, 0, mmRLC_CSIB_ADDR_HI,
+   WREG32_SOC15_RLC(GC, 0, mmRLC_CSIB_ADDR_HI,
 adev->gfx.rlc.clear_state_gpu_addr >> 32);
-   WREG32_SOC15(GC, 0, mmRLC_CSIB_ADDR_LO,
+   WREG32_SOC15_RLC(GC, 0, mmRLC_CSIB_ADDR_LO,
 adev->gfx.rlc.clear_state_gpu_addr & 0xfffc);
-   WREG32_SOC15(GC, 0, mmRLC_CSIB_LENGTH, adev->gfx.rlc.clear_state_size);
+   WREG32_SOC15_RLC(GC, 0, mmRLC_CSIB_LENGTH, 
adev->gfx.rlc.clear_state_size);
 
return 0;
 }
@@ -2395,7 +2395,7 @@ static int gfx_v10_0_cp_gfx_enable(struct amdgpu_device 
*adev, bool enable)
for (i = 0; i < adev->gfx.num_gfx_rings; i++)
adev->gfx.gfx_ring[i].sched.ready = false;
}
-   WREG32_SOC15(GC, 0, mmCP_ME_CNTL, tmp);
+   WREG32_SOC15_RLC(GC, 0, mmCP_ME_CNTL, tmp);
 
for (i = 0; i < adev->usec_timeout; i++) {
if (RREG32_SOC15(GC, 0, mmCP_STAT) == 0)
-- 
2.17.1

___
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-gfxdata=02%7C01%7Cmonk.liu%40amd.com%7C623a44a5ca41457bc1bc08d7ba660464%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637182819663774681sdata=zyLVEDjoZmkh9zEGtR%2FqWNA7J0aO4wl3jnYqrvwBn1Y%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC PATCH 2/4] drm/scheduler: implement a function to modify sched list

[Luben Tuikov]

On 2020-02-27 4:40 p.m., Nirmoy Das wrote:
> implement drm_sched_entity_modify_sched() which can modify existing
> sched_list with a different one. This is going to be helpful when
> userspace changes priority of a ctx/entity then driver can switch to
> corresponding hw shced list for that priority
> 
> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/scheduler/sched_entity.c | 24 
>  include/drm/gpu_scheduler.h  |  4 
>  2 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
> b/drivers/gpu/drm/scheduler/sched_entity.c
> index 63bccd201b97..711e9d504bcb 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -83,6 +83,30 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
>  }
>  EXPORT_SYMBOL(drm_sched_entity_init);
>  
> +/**
> + * drm_sched_entity_modify_sched - Modify sched of an entity
> + *
> + * @entity: scheduler entity to init
> + * @sched_list: the list of new drm scheds which will replace
> + *   existing entity->sched_list
> + * @num_sched_list: number of drm sched in sched_list
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
> +   struct drm_gpu_scheduler **sched_list,
> +   unsigned int num_sched_list)
> +{
> + if (!(entity && sched_list && (num_sched_list == 0 || sched_list[0])))
> + return -EINVAL;

This seems unmaintainable. I'd write it in its natural form:

int drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
  struct drm_gpu_scheduler **sched_list,
  unsigned int num_sched_list)
{
if (entity && sched_list && (num_sched_list == 0 || sched_list[0] != 
NULL)) {
entity->sched_list = num_sched_list > 1 ? sched_list : NULL;
entity->num_sched_list = num_sched_list;
return 0;
} else {
return -EINVAL;
}
}

That's too heavy. Can we improve the architecture
so we don't have to check for this in leaf functions like this one?
We can just return a parameterization.

Why would this be called with entity being NULL?
Or with sched_list being NULL? Or num_sched_list being not zero
yet sched_list[0] being NULL? Why not make sure that sched_list[0] is
never NULL and that num_sched_list is greater than 0 always?

Does this make it to user space?
Why would the state of execution be one such that this is true/false
for the code to return -EINVAL?
>From patch 3/4 it seems that an error is printed inside 
>amdgpu_ctx_priority_override()
and the result is not propagated up the stack.

I think we should improve the code where here this condition above
is never true. Then we can use parameterization for those two
statements below:

> +
> + entity->sched_list = num_sched_list > 1 ? sched_list : NULL;

So if we're here, we know from the top conditional that
either num_sched_list is 0 or that sched_list[0] not NULL
or both.

So if num_sched_list is 0 or 1 we return NULL?
And if num_sched_list is 2 or greater we return sched_list
of which sched_list[0] could be NULL?

Why not fix the architecture so that this is simply copied? (in which case
we can simply index-parameterize it and simply copy it.
Why are there so many checks everywhere?

> + entity->num_sched_list = num_sched_list;
> +

I mean, all we're doing in this function is initializing
entity->sched_list and entity->num_sched_list. Why does this
function have to be so complex and do so many checks?
Can we improve/fix the architecture instead?

Regards,
Luben


> + return 0;
> +}
> +EXPORT_SYMBOL(drm_sched_entity_modify_sched);
> +
>  /**
>   * drm_sched_entity_is_idle - Check if entity is idle
>   *
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 589be851f8a1..0c164a96d51b 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -297,6 +297,10 @@ void drm_sched_fini(struct drm_gpu_scheduler *sched);
>  int drm_sched_job_init(struct drm_sched_job *job,
>  struct drm_sched_entity *entity,
>  void *owner);
> +int drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
> +   struct drm_gpu_scheduler **sched_list,
> +  unsigned int num_sched_list);
> +
>  void drm_sched_job_cleanup(struct drm_sched_job *job);
>  void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
>  void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job 
> *bad);
> 

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

RE: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14

[Quan, Evan]

Please add proper lock in smu_set_soft_freq_range() then.
You can do necessary modification to existing code paths.
Otherwise without lock protection, you may run into race condition on the new 
debugfs intrace(amdgpu_debugfs_sclk_set) called by multiple instances.

-Original Message-
From: Gui, Jack  
Sent: Friday, February 28, 2020 12:35 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth ; Xu, Feifei 
Subject: RE: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary 
sclk for navi14

[AMD Official Use Only - Internal Distribution Only]

Hi Evan,

No lock is created for smu_set_soft_freq_range() in this code path.
But some other sysfs interfaces calling  smu_set_soft_freq_range() indirectly 
have created lock in middle function to protect  smu_set_soft_freq_range() as 
critical resource.
So, if we want to lock the "issue message action" in smu_set_soft_freq_range(), 
another patch is needed.

BR,
Jack

-Original Message-
From: Quan, Evan 
Sent: Friday, February 28, 2020 11:37 AM
To: Gui, Jack ; amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth ; Xu, Feifei ; Gui, 
Jack 
Subject: RE: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary 
sclk for navi14

Please confirm whether smu_set_soft_freq_range() is properly lock protected.

-Original Message-
From: Chengming Gui 
Sent: Friday, February 28, 2020 10:37 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Feng, Kenneth ; Xu, 
Feifei ; Gui, Jack 
Subject: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk 
for navi14

add debugfs interface amdgpu_force_sclk
to set arbitrary sclk for navi14

Signed-off-by: Chengming Gui 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 44 ++
 drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h |  3 ++
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 3bb7405..5ee7e92 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1269,9 +1269,43 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
return 0;
 }
 
+static int amdgpu_debugfs_sclk_set(void *data, u64 val) {
+   int ret = 0;
+   uint32_t max_freq, min_freq;
+   struct amdgpu_device *adev = (struct amdgpu_device *)data;
+
+   if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
+   return -EINVAL;
+
+   ret = pm_runtime_get_sync(adev->ddev->dev);
+   if (ret < 0)
+   return ret;
+
+   if (is_support_sw_smu(adev)) {
+   ret = smu_get_dpm_freq_range(>smu, SMU_SCLK, _freq, 
_freq, true);
+   if (ret || val > max_freq || val < min_freq)
+   return -EINVAL;
+   ret = smu_set_soft_freq_range(>smu, SMU_SCLK, 
(uint32_t)val, (uint32_t)val);
+   } else {
+   return 0;
+   }
+
+   pm_runtime_mark_last_busy(adev->ddev->dev);
+   pm_runtime_put_autosuspend(adev->ddev->dev);
+
+   if (ret)
+   return -EINVAL;
+
+   return 0;
+}
+
 DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL,
amdgpu_debugfs_ib_preempt, "%llu\n");
 
+DEFINE_SIMPLE_ATTRIBUTE(fops_sclk_set, NULL,
+   amdgpu_debugfs_sclk_set, "%llu\n");
+
 int amdgpu_debugfs_init(struct amdgpu_device *adev)  {
int r, i;
@@ -1285,6 +1319,15 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
return -EIO;
}
 
+   adev->smu.debugfs_sclk =
+   debugfs_create_file("amdgpu_force_sclk", 0200,
+   adev->ddev->primary->debugfs_root, adev,
+   _sclk_set);
+   if (!(adev->smu.debugfs_sclk)) {
+   DRM_ERROR("unable to create amdgpu_set_sclk debugsfs file\n");
+   return -EIO;
+   }
+
/* Register debugfs entries for amdgpu_ttm */
r = amdgpu_ttm_debugfs_init(adev);
if (r) {
@@ -1353,6 +1396,7 @@ void amdgpu_debugfs_fini(struct amdgpu_device *adev)
}
amdgpu_ttm_debugfs_fini(adev);
debugfs_remove(adev->debugfs_preempt);
+   debugfs_remove(adev->smu.debugfs_sclk);
 }
 
 #else
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
index 97b6714..36fe19c 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
@@ -371,6 +371,9 @@ struct smu_context
struct amd_pp_display_configuration  *display_config;
struct smu_baco_context smu_baco;
void *od_settings;
+#if defined(CONFIG_DEBUG_FS)
+   struct dentry   *debugfs_sclk;
+#endif
 
uint32_t pstate_sclk;
uint32_t pstate_mclk;
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org

RE: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14

[Gui, Jack]

[AMD Official Use Only - Internal Distribution Only]

Hi Evan,

No lock is created for smu_set_soft_freq_range() in this code path.
But some other sysfs interfaces calling  smu_set_soft_freq_range() indirectly
have created lock in middle function to protect  smu_set_soft_freq_range() as 
critical resource.
So, if we want to lock the "issue message action" in smu_set_soft_freq_range(), 
another patch is needed.

BR,
Jack

-Original Message-
From: Quan, Evan  
Sent: Friday, February 28, 2020 11:37 AM
To: Gui, Jack ; amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth ; Xu, Feifei ; Gui, 
Jack 
Subject: RE: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary 
sclk for navi14

Please confirm whether smu_set_soft_freq_range() is properly lock protected.

-Original Message-
From: Chengming Gui 
Sent: Friday, February 28, 2020 10:37 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Feng, Kenneth ; Xu, 
Feifei ; Gui, Jack 
Subject: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk 
for navi14

add debugfs interface amdgpu_force_sclk
to set arbitrary sclk for navi14

Signed-off-by: Chengming Gui 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 44 ++
 drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h |  3 ++
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 3bb7405..5ee7e92 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1269,9 +1269,43 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
return 0;
 }
 
+static int amdgpu_debugfs_sclk_set(void *data, u64 val) {
+   int ret = 0;
+   uint32_t max_freq, min_freq;
+   struct amdgpu_device *adev = (struct amdgpu_device *)data;
+
+   if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
+   return -EINVAL;
+
+   ret = pm_runtime_get_sync(adev->ddev->dev);
+   if (ret < 0)
+   return ret;
+
+   if (is_support_sw_smu(adev)) {
+   ret = smu_get_dpm_freq_range(>smu, SMU_SCLK, _freq, 
_freq, true);
+   if (ret || val > max_freq || val < min_freq)
+   return -EINVAL;
+   ret = smu_set_soft_freq_range(>smu, SMU_SCLK, 
(uint32_t)val, (uint32_t)val);
+   } else {
+   return 0;
+   }
+
+   pm_runtime_mark_last_busy(adev->ddev->dev);
+   pm_runtime_put_autosuspend(adev->ddev->dev);
+
+   if (ret)
+   return -EINVAL;
+
+   return 0;
+}
+
 DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL,
amdgpu_debugfs_ib_preempt, "%llu\n");
 
+DEFINE_SIMPLE_ATTRIBUTE(fops_sclk_set, NULL,
+   amdgpu_debugfs_sclk_set, "%llu\n");
+
 int amdgpu_debugfs_init(struct amdgpu_device *adev)  {
int r, i;
@@ -1285,6 +1319,15 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
return -EIO;
}
 
+   adev->smu.debugfs_sclk =
+   debugfs_create_file("amdgpu_force_sclk", 0200,
+   adev->ddev->primary->debugfs_root, adev,
+   _sclk_set);
+   if (!(adev->smu.debugfs_sclk)) {
+   DRM_ERROR("unable to create amdgpu_set_sclk debugsfs file\n");
+   return -EIO;
+   }
+
/* Register debugfs entries for amdgpu_ttm */
r = amdgpu_ttm_debugfs_init(adev);
if (r) {
@@ -1353,6 +1396,7 @@ void amdgpu_debugfs_fini(struct amdgpu_device *adev)
}
amdgpu_ttm_debugfs_fini(adev);
debugfs_remove(adev->debugfs_preempt);
+   debugfs_remove(adev->smu.debugfs_sclk);
 }
 
 #else
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
index 97b6714..36fe19c 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
@@ -371,6 +371,9 @@ struct smu_context
struct amd_pp_display_configuration  *display_config;
struct smu_baco_context smu_baco;
void *od_settings;
+#if defined(CONFIG_DEBUG_FS)
+   struct dentry   *debugfs_sclk;
+#endif
 
uint32_t pstate_sclk;
uint32_t pstate_mclk;
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC PATCH 3/4] drm/amdgpu: change hw sched list on ctx priority override

[Luben Tuikov]

On 2020-02-27 4:40 p.m., Nirmoy Das wrote:
> Switch to appropriate sched list for an entity on priority override.
> 
> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 54 -
>  1 file changed, 53 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> index a1742b1d4f9c..69a791430b25 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> @@ -508,11 +508,53 @@ struct dma_fence *amdgpu_ctx_get_fence(struct 
> amdgpu_ctx *ctx,
>   return fence;
>  }
>  
> +static int amdgpu_ctx_change_sched(struct amdgpu_ctx *ctx,
> +struct amdgpu_ctx_entity *aentity,
> +int hw_ip, enum drm_sched_priority priority)
> +{
> + struct amdgpu_device *adev = ctx->adev;
> + struct drm_gpu_scheduler **scheds = NULL;
> + unsigned num_scheds = 0;
> +
> + switch (hw_ip) {
> + case AMDGPU_HW_IP_COMPUTE:

NAK. Don't indent the "case".

LKCS says that "case" must not be indented:
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#indentation

> + if (priority > DRM_SCHED_PRIORITY_NORMAL &&
> + adev->gfx.num_compute_sched_high) {
> + scheds = adev->gfx.compute_sched_high;
> + num_scheds = adev->gfx.num_compute_sched_high;
> + } else {
> + scheds = adev->gfx.compute_sched;
> + num_scheds = adev->gfx.num_compute_sched;
> + }

I feel that this is a regression in that we're having an if-conditional
inside a switch-case. Could use just use maps to execute without
any branching?

Surely priority could be used as an index into a map of DRM_SCHED_PRIORITY_MAX
to find out which scheduler to use and the number thereof.

> + break;
> + default:
> + return 0;
> + }


> +
> + return drm_sched_entity_modify_sched(>entity, scheds, 
> num_scheds);
> +}
> +
> +static int amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx,
> + const u32 hw_ip,
> + enum drm_sched_priority priority)
> +{
> + int r = 0, i;
> +
> + for (i = 0; i < amdgpu_ctx_num_entities[hw_ip]; ++i) {
> + if (!ctx->entities[hw_ip][i])
> + continue;
> + r = amdgpu_ctx_change_sched(ctx, ctx->entities[hw_ip][i],
> + hw_ip, priority);
> + }
> +
> + return r;
> +}
> +
>  void amdgpu_ctx_priority_override(struct amdgpu_ctx *ctx,
> enum drm_sched_priority priority)
>  {
>   enum drm_sched_priority ctx_prio;
> - unsigned i, j;
> + unsigned r, i, j;
>  
>   ctx->override_priority = priority;
>  
> @@ -521,11 +563,21 @@ void amdgpu_ctx_priority_override(struct amdgpu_ctx 
> *ctx,
>   for (i = 0; i < AMDGPU_HW_IP_NUM; ++i) {
>   for (j = 0; j < amdgpu_ctx_num_entities[i]; ++j) {
>   struct drm_sched_entity *entity;
> + struct amdgpu_ring *ring;
>  
>   if (!ctx->entities[i][j])
>   continue;
>  
>   entity = >entities[i][j]->entity;
> + ring = to_amdgpu_ring(entity->rq->sched);
> +
> + if (ring->high_priority) {
> + r = amdgpu_ctx_hw_priority_override(ctx, i,
> + ctx_prio);
> + if (r)
> + DRM_ERROR("Failed to override HW 
> priority for %s",
> +   ring->name);
> + }

I can't see this an an improvement when we add branching inside a for-loop.
Perhaps if we remove if-conditionals and use indexing to eliminate
branching?

Regards,
Luben

>   drm_sched_entity_set_priority(entity, ctx_prio);
>   }
>   }
> 

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

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

[Luben Tuikov]

On 2020-02-26 3:37 p.m., Nirmoy Das wrote:
> We were changing compute ring priority while rings were being used
> before every job submission which is not recommended. This patch
> recreates entity with higher/normal priority sched list when user
> changes ctx's priority.
> 
> high/normal priority sched list are generated from set of high/normal
> priority compute queues. When there are no high priority hw queues then
> it fall backs to software priority.
> 
> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  4 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 58 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h  |  2 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  6 ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c |  4 ++
>  5 files changed, 59 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index f397ff97b4e4..8304d0c87899 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -1205,7 +1205,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
>   struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
>   struct drm_sched_entity *entity = p->entity;
>   enum drm_sched_priority priority;
> - struct amdgpu_ring *ring;
>   struct amdgpu_bo_list_entry *e;
>   struct amdgpu_job *job;
>   uint64_t seq;
> @@ -1258,9 +1257,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
>   priority = job->base.s_priority;
>   drm_sched_entity_push_job(>base, entity);
>  
> - ring = to_amdgpu_ring(entity->rq->sched);
> - amdgpu_ring_priority_get(ring, priority);
> -
>   amdgpu_vm_move_to_lru_tail(p->adev, >vm);
>  
>   ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> index 94a6c42f29ea..ea4dc57d2237 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> @@ -85,8 +85,13 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, 
> const u32 hw_ip, const
>   num_scheds = 1;
>   break;
>   case AMDGPU_HW_IP_COMPUTE:
> - scheds = adev->gfx.compute_sched;
> - num_scheds = adev->gfx.num_compute_sched;
> + if (priority <= DRM_SCHED_PRIORITY_NORMAL) {
> + scheds = adev->gfx.compute_sched;
> + num_scheds = adev->gfx.num_compute_sched;
> + } else {
> + scheds = adev->gfx.compute_sched_high;
> + num_scheds = adev->gfx.num_compute_sched_high;
> + }

Why more if-conditionals?

If you initialize a map of DRM_SCHED_PRIORITY_MAX of type then you can simply 
do:

scheds = adev->gfx.map[priority];

So, part of your array would contain normal and the rest high.

Also, I don't think you should introduce yet another
compute_sched[] array. All this should be folded into
a single array containing both normal and high.

Also consider changing to this:

enum drm_sched_priority {
DRM_SCHED_PRIORITY_UNSET,
DRM_SCHED_PRIORITY_INVALID,<--- remove
DRM_SCHED_PRIORITY_MIN,
DRM_SCHED_PRIORITY_LOW = DRM_SCHED_PRIORITY_MIN,
DRM_SCHED_PRIORITY_NORMAL,
DRM_SCHED_PRIORITY_HIGH_SW,
DRM_SCHED_PRIORITY_HIGH_HW,
DRM_SCHED_PRIORITY_KERNEL,
DRM_SCHED_PRIORITY_MAX,
};

We should never have an "invalid priority", just ignored priority. :-)
Second, having 0 as UNSET gives you easy priority when you set
map[0] = normal_priority, as memory usually comes memset to 0.
IOW, you'd not need to check against UNSET, and simply use
the default [0] which you'd set to normal priority.

>   break;
>   case AMDGPU_HW_IP_DMA:
>   scheds = adev->sdma.sdma_sched;
> @@ -502,6 +507,24 @@ struct dma_fence *amdgpu_ctx_get_fence(struct amdgpu_ctx 
> *ctx,
>   return fence;
>  }
>  
> +static void amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx,
> + const u32 hw_ip,
> + enum drm_sched_priority priority)
> +{
> + int i;
> +
> + for (i = 0; i < amdgpu_ctx_num_entities[hw_ip]; ++i) {
> + if (!ctx->entities[hw_ip][i])
> + continue;
> +
> + /* TODO what happens with prev scheduled jobs */
> + drm_sched_entity_destroy(>entities[hw_ip][i]->entity);
> + amdgpu_ctx_fini_entity(ctx->entities[hw_ip][i]);
> +
> + amdgpu_ctx_init_entity(ctx, AMDGPU_HW_IP_COMPUTE, i);
> +
> + }
> +}
>  void amdgpu_ctx_priority_override(struct amdgpu_ctx *ctx,
> enum drm_sched_priority priority)
>  {
> @@ -515,12 

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Dave Airlie]

On Fri, 28 Feb 2020 at 07:27, Daniel Vetter  wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
>
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
>
> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
>
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.

a) Ouch.

b) we probably need to take a large step back here.

Look at this from a sponsor POV, why would I give X.org/fd.o
sponsorship money that they are just giving straight to google to pay
for hosting credits? Google are profiting in some minor way from these
hosting credits being bought by us, and I assume we aren't getting any
sort of discounts here. Having google sponsor the credits costs google
substantially less than having any other company give us money to do
it.

If our current CI architecture is going to burn this amount of money a
year and we hadn't worked this out in advance of deploying it then I
suggest the system should be taken offline until we work out what a
sustainable system would look like within the budget we have, whether
that be never transferring containers and build artifacts from the
google network, just having local runner/build combos etc.

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

RE: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14

[Quan, Evan]

Please confirm whether smu_set_soft_freq_range() is properly lock protected.

-Original Message-
From: Chengming Gui  
Sent: Friday, February 28, 2020 10:37 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Feng, Kenneth ; Xu, 
Feifei ; Gui, Jack 
Subject: [PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk 
for navi14

add debugfs interface amdgpu_force_sclk
to set arbitrary sclk for navi14

Signed-off-by: Chengming Gui 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 44 ++
 drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h |  3 ++
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 3bb7405..5ee7e92 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1269,9 +1269,43 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
return 0;
 }
 
+static int amdgpu_debugfs_sclk_set(void *data, u64 val)
+{
+   int ret = 0;
+   uint32_t max_freq, min_freq;
+   struct amdgpu_device *adev = (struct amdgpu_device *)data;
+
+   if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
+   return -EINVAL;
+
+   ret = pm_runtime_get_sync(adev->ddev->dev);
+   if (ret < 0)
+   return ret;
+
+   if (is_support_sw_smu(adev)) {
+   ret = smu_get_dpm_freq_range(>smu, SMU_SCLK, _freq, 
_freq, true);
+   if (ret || val > max_freq || val < min_freq)
+   return -EINVAL;
+   ret = smu_set_soft_freq_range(>smu, SMU_SCLK, 
(uint32_t)val, (uint32_t)val);
+   } else {
+   return 0;
+   }
+
+   pm_runtime_mark_last_busy(adev->ddev->dev);
+   pm_runtime_put_autosuspend(adev->ddev->dev);
+
+   if (ret)
+   return -EINVAL;
+
+   return 0;
+}
+
 DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL,
amdgpu_debugfs_ib_preempt, "%llu\n");
 
+DEFINE_SIMPLE_ATTRIBUTE(fops_sclk_set, NULL,
+   amdgpu_debugfs_sclk_set, "%llu\n");
+
 int amdgpu_debugfs_init(struct amdgpu_device *adev)
 {
int r, i;
@@ -1285,6 +1319,15 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
return -EIO;
}
 
+   adev->smu.debugfs_sclk =
+   debugfs_create_file("amdgpu_force_sclk", 0200,
+   adev->ddev->primary->debugfs_root, adev,
+   _sclk_set);
+   if (!(adev->smu.debugfs_sclk)) {
+   DRM_ERROR("unable to create amdgpu_set_sclk debugsfs file\n");
+   return -EIO;
+   }
+
/* Register debugfs entries for amdgpu_ttm */
r = amdgpu_ttm_debugfs_init(adev);
if (r) {
@@ -1353,6 +1396,7 @@ void amdgpu_debugfs_fini(struct amdgpu_device *adev)
}
amdgpu_ttm_debugfs_fini(adev);
debugfs_remove(adev->debugfs_preempt);
+   debugfs_remove(adev->smu.debugfs_sclk);
 }
 
 #else
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
index 97b6714..36fe19c 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
@@ -371,6 +371,9 @@ struct smu_context
struct amd_pp_display_configuration  *display_config;
struct smu_baco_context smu_baco;
void *od_settings;
+#if defined(CONFIG_DEBUG_FS)
+   struct dentry   *debugfs_sclk;
+#endif
 
uint32_t pstate_sclk;
uint32_t pstate_mclk;
-- 
2.7.4

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

RE: [PATCH 1/2] Revert "drm/amdgpu: add sysfs interface to set arbitrary sclk value for navi14"

[Quan, Evan]

Reviewed-by: Evan Quan 

-Original Message-
From: Chengming Gui  
Sent: Friday, February 28, 2020 10:37 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Feng, Kenneth ; Xu, 
Feifei ; Gui, Jack 
Subject: [PATCH 1/2] Revert "drm/amdgpu: add sysfs interface to set arbitrary 
sclk value for navi14"

Revert this commit and than add debugfs interface to replace this to meet the 
specitic requirement.

This reverts commit 3107269204f8e18f389080673f7848b420970aa5.
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 42 ---
 drivers/gpu/drm/amd/powerplay/smu_v11_0.c |  9 ++-
 2 files changed, 2 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 9deff8c..bc3cf04 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1034,40 +1034,6 @@ static ssize_t amdgpu_read_mask(const char *buf, size_t 
count, uint32_t *mask)
return 0;
 }
 
-static ssize_t amdgpu_set_pp_sclk(struct device *dev,
-   struct device_attribute *attr,
-   const char *buf,
-   size_t count)
-{
-   struct drm_device *ddev = dev_get_drvdata(dev);
-   struct amdgpu_device *adev = ddev->dev_private;
-   int ret;
-   uint32_t value;
-
-   if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
-   return -EINVAL;
-
-   ret = pm_runtime_get_sync(ddev->dev);
-   if (ret < 0)
-   return ret;
-
-   ret = kstrtou32(buf, 0, );
-   if (ret < 0)
-   return ret;
-   if (is_support_sw_smu(adev))
-   ret = smu_set_soft_freq_range(>smu, SMU_SCLK, value, 
value);
-   else
-   return 0;
-
-   pm_runtime_mark_last_busy(ddev->dev);
-   pm_runtime_put_autosuspend(ddev->dev);
-
-   if (ret)
-   return -EINVAL;
-
-   return count;
-}
-
 static ssize_t amdgpu_set_pp_dpm_sclk(struct device *dev,
struct device_attribute *attr,
const char *buf,
@@ -1829,8 +1795,6 @@ static DEVICE_ATTR(pp_force_state, S_IRUGO | S_IWUSR,  
static DEVICE_ATTR(pp_table, S_IRUGO | S_IWUSR,
amdgpu_get_pp_table,
amdgpu_set_pp_table);
-static DEVICE_ATTR(pp_sclk, S_IWUSR,
-   NULL, amdgpu_set_pp_sclk);
 static DEVICE_ATTR(pp_dpm_sclk, S_IRUGO | S_IWUSR,
amdgpu_get_pp_dpm_sclk,
amdgpu_set_pp_dpm_sclk);
@@ -3322,12 +3286,6 @@ int amdgpu_pm_sysfs_init(struct amdgpu_device *adev)
return ret;
}
 
-   ret = device_create_file(adev->dev, _attr_pp_sclk);
-   if (ret) {
-   DRM_ERROR("failed to create device file pp_sclk\n");
-   return ret;
-   }
-
ret = device_create_file(adev->dev, _attr_pp_dpm_sclk);
if (ret) {
DRM_ERROR("failed to create device file pp_dpm_sclk\n"); diff 
--git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c 
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index 1507bb7..c9e5ce1 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -1803,17 +1803,12 @@ int smu_v11_0_set_soft_freq_limited_range(struct 
smu_context *smu, enum smu_clk_  {
int ret = 0, clk_id = 0;
uint32_t param;
-   uint32_t min_freq, max_freq;
 
clk_id = smu_clk_get_index(smu, clk_type);
if (clk_id < 0)
return clk_id;
 
-   ret = smu_get_dpm_freq_range(smu, clk_type, _freq, _freq, true);
-   if (ret)
-   return ret;
-
-   if (max > 0 && max <=  max_freq) {
+   if (max > 0) {
param = (uint32_t)((clk_id << 16) | (max & 0x));
ret = smu_send_smc_msg_with_param(smu, SMU_MSG_SetSoftMaxByFreq,
  param);
@@ -1821,7 +1816,7 @@ int smu_v11_0_set_soft_freq_limited_range(struct 
smu_context *smu, enum smu_clk_
return ret;
}
 
-   if (min > 0 && min >= min_freq) {
+   if (min > 0) {
param = (uint32_t)((clk_id << 16) | (min & 0x));
ret = smu_send_smc_msg_with_param(smu, SMU_MSG_SetSoftMinByFreq,
  param);
--
2.7.4

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

Re: [RFC PATCH 1/3] drm/amdgpu: implement ring init_priority for compute ring

[Luben Tuikov]

On 2020-02-26 3:37 p.m., Nirmoy Das wrote:
> init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high 
> priority
> and 1st queue to normal priority.
> 
> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 ++
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 +
>  3 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 24caff085d00..a109373b9fe8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -170,6 +170,7 @@ struct amdgpu_ring_funcs {
>   /* priority functions */
>   void (*set_priority) (struct amdgpu_ring *ring,
> enum drm_sched_priority priority);
> + void (*init_priority) (struct amdgpu_ring *ring);
>   /* Try to soft recover the ring to make the fence signal */
>   void (*soft_recovery)(struct amdgpu_ring *ring, unsigned vmid);
>   int (*preempt_ib)(struct amdgpu_ring *ring);
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index fa245973de12..14bab6e08bd6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -6334,6 +6334,19 @@ static void gfx_v8_0_ring_set_priority_compute(struct 
> amdgpu_ring *ring,
>   gfx_v8_0_pipe_reserve_resources(adev, ring, acquire);
>  }
> 
> +static void gfx_v8_0_ring_init_priority_compute(struct amdgpu_ring *ring)

Why two verbs in this function: "init" and "compute"?
Certainly there is no need for "compute".
Just call it

gfx_blah_ring_priority_init()

Putting the object first and the verb last, as is commonly done.

> +{
> + /* set pipe 0 to normal priority and pipe 1 to high priority*/
> + if (ring->queue == 1) {
> + gfx_v8_0_hqd_set_priority(ring->adev, ring, true);
> + gfx_v8_0_ring_set_pipe_percent(ring, true);
> + } else {
> + gfx_v8_0_hqd_set_priority(ring->adev, ring, false);
> + gfx_v8_0_ring_set_pipe_percent(ring, false);
> + }
> +
> +}

Again. Notice that the only difference between the two outcomes
of the conditional is the last parameter to both.

So you could write your code like this:

gfx_v8_0_hqd_set_priority(ring->adev, ring, ring->queue == 1);
gfx_v8_0_ring_set_pipe_percent(ring, ring->queue == 1);

Further more if "priority" had to be variable value,
I'd parameterize it in a map (i.e. array) and use
a computed index to index the map in order to retrieve
the variabled "priority". This eliminates if-conditionals.

Note in general that we want less if-conditionals,
in the execution path and more streamline execution.

> +
>  static void gfx_v8_0_ring_emit_fence_compute(struct amdgpu_ring *ring,
>u64 addr, u64 seq,
>unsigned flags)
> @@ -6967,6 +6980,7 @@ static const struct amdgpu_ring_funcs 
> gfx_v8_0_ring_funcs_compute = {
>   .insert_nop = amdgpu_ring_insert_nop,
>   .pad_ib = amdgpu_ring_generic_pad_ib,
>   .set_priority = gfx_v8_0_ring_set_priority_compute,
> + .init_priority = gfx_v8_0_ring_init_priority_compute,
>   .emit_wreg = gfx_v8_0_ring_emit_wreg,
>  };
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 1c7a16b91686..0c66743fb6f5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -5143,6 +5143,18 @@ static void gfx_v9_0_ring_set_priority_compute(struct 
> amdgpu_ring *ring,
>   gfx_v9_0_pipe_reserve_resources(adev, ring, acquire);
>  }
> 
> +static void gfx_v9_0_ring_init_priority_compute(struct amdgpu_ring *ring)

Ditto for this name as per above.

> +{
> + /* set pipe 0 to normal priority and pipe 1 to high priority*/
> + if (ring->queue == 1) {
> + gfx_v9_0_hqd_set_priority(ring->adev, ring, true);
> + gfx_v9_0_ring_set_pipe_percent(ring, true);
> + } else {
> + gfx_v9_0_hqd_set_priority(ring->adev, ring, false);
> + gfx_v9_0_ring_set_pipe_percent(ring, true);
> + }
> +}

Note how similar this is to the v8 above?
Those could be made the same and he vX parameterized to
the correct implementation.

For instance, if you parameterize the "gfx_vX_0_hqd_set_priority()"
and "gfx_vX_0_ring_set_pipe_percent()". Then your code becomes,
like this pseudo-code:

ring_init_set_priority(ring)
{
map = ring->property[ring->version];

map->hqd_priority_set(ring->adev, ring, ring->queue == 1);
map->ring_pipe_percent_set(ring, ring->queue == 1);
}

Regards,
Luben


> +
>  static void gfx_v9_0_ring_set_wptr_compute(struct amdgpu_ring *ring)
>  {
>   struct amdgpu_device *adev = ring->adev;
> @@ -6514,6 +6526,7 @@ static const struct amdgpu_ring_funcs 
> 

Re: [PATCH] drm/amdgpu/sriov: Use VF-accessible register for gpu_clock_count

[Zhao, Jiange]

Hi,

I got feedback from Linux team and they simply don't want to change.

I believe that it would work for bare metal as well.

Jiange

From: Deucher, Alexander 
Sent: Thursday, February 27, 2020 10:23 PM
To: Zhao, Jiange ; amd-gfx@lists.freedesktop.org 

Cc: Deng, Emily ; Liu, Monk 
Subject: Re: [PATCH] drm/amdgpu/sriov: Use VF-accessible register for 
gpu_clock_count


[AMD Public Use]

Is there any reason to not just use this for bare metal as well?

Alex


From: amd-gfx  on behalf of jianzh 

Sent: Thursday, February 27, 2020 6:21 AM
To: amd-gfx@lists.freedesktop.org 
Cc: Deng, Emily ; Zhao, Jiange ; Liu, 
Monk 
Subject: [PATCH] drm/amdgpu/sriov: Use VF-accessible register for 
gpu_clock_count

Navi12 VK CTS subtest timestamp.calibrated.dev_domain_test failed
because mmRLC_CAPTURE_GPU_CLOCK_COUNT register cannot be
written in VF due to security policy.

Solution: use a VF-accessible timestamp register pair
mmGOLDEN_TSC_COUNT_LOWER/UPPER for SRIOV case.

Signed-off-by: jianzh 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 44f00ec..8787a46 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -35,6 +35,8 @@

 #include "gc/gc_10_1_0_offset.h"
 #include "gc/gc_10_1_0_sh_mask.h"
+#include "smuio/smuio_11_0_0_offset.h"
+#include "smuio/smuio_11_0_0_sh_mask.h"
 #include "navi10_enum.h"
 #include "hdp/hdp_5_0_0_offset.h"
 #include "ivsrcid/gfx/irqsrcs_gfx_10_1.h"
@@ -3920,9 +3922,14 @@ static uint64_t gfx_v10_0_get_gpu_clock_counter(struct 
amdgpu_device *adev)

 amdgpu_gfx_off_ctrl(adev, false);
 mutex_lock(>gfx.gpu_clock_mutex);
-   WREG32_SOC15(GC, 0, mmRLC_CAPTURE_GPU_CLOCK_COUNT, 1);
-   clock = (uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_LSB) |
-   ((uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_MSB) << 
32ULL);
+   if (!amdgpu_sriov_vf(adev)) {
+   WREG32_SOC15(GC, 0, mmRLC_CAPTURE_GPU_CLOCK_COUNT, 1);
+   clock = (uint64_t)RREG32_SOC15(GC, 0, 
mmRLC_GPU_CLOCK_COUNT_LSB) |
+   ((uint64_t)RREG32_SOC15(GC, 0, 
mmRLC_GPU_CLOCK_COUNT_MSB) << 32ULL);
+   } else {
+   clock = (uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER) |
+   ((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER) << 32ULL);
+   }
 mutex_unlock(>gfx.gpu_clock_mutex);
 amdgpu_gfx_off_ctrl(adev, true);
 return clock;
--
2.7.4

___
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-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C9b14a49e41fd48f7138f08d7bb773ed9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183993593225894sdata=jFUVpgeEcTTJbTJ3a7ibAPOyAU3RVF%2FEIN41zaqS0eM%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

[Quan, Evan]

Thanks. But could you help to confirm whether this is correctly protected by 
"mutex_lock(>mutex)"?

-Original Message-
From: Hersen Wu  
Sent: Thursday, February 27, 2020 11:54 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Feng, Kenneth ; Wu, 
Hersen 
Subject: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock 
settings to smu resume from s3

 This interface is for dGPU Navi1x. Linux dc-pplib interface depends  on window 
driver dc implementation.

 For Navi1x, clock settings of dcn watermarks are fixed. the settings  should 
be passed to smu during boot up and resume from s3.
 boot up: dc calculate dcn watermark clock settings within dc_create,  
dcn20_resource_construct, then call pplib functions below to pass  the settings 
to smu:
 smu_set_watermarks_for_clock_ranges
 smu_set_watermarks_table
 navi10_set_watermarks_table
 smu_write_watermarks_table

 For Renoir, clock settings of dcn watermark are also fixed values.
 dc has implemented different flow for window driver:
 dc_hardware_init / dc_set_power_state
 dcn10_init_hw
 notify_wm_ranges
 set_wm_ranges

 For Linux
 smu_set_watermarks_for_clock_ranges
 renoir_set_watermarks_table
 smu_write_watermarks_table

 dc_hardware_init -> amdgpu_dm_init
 dc_set_power_state --> dm_resume

 therefore, linux dc-pplib interface of navi10/12/14 is different  from that of 
Renoir.

Signed-off-by: Hersen Wu 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 64 +++
 1 file changed, 64 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 931cbd7b372e..c58c0e95735e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1435,6 +1435,68 @@ static void s3_handle_mst(struct drm_device *dev, bool 
suspend)
drm_kms_helper_hotplug_event(dev);
 }
 
+static int amdgpu_dm_smu_write_watermarks_table(struct amdgpu_device 
+*adev) {
+   struct smu_context *smu = >smu;
+   int ret = 0;
+
+   if (!is_support_sw_smu(adev))
+   return 0;
+
+   /* This interface is for dGPU Navi1x.Linux dc-pplib interface depends
+* on window driver dc implementation.
+* For Navi1x, clock settings of dcn watermarks are fixed. the settings
+* should be passed to smu during boot up and resume from s3.
+* boot up: dc calculate dcn watermark clock settings within dc_create,
+* dcn20_resource_construct
+* then call pplib functions below to pass the settings to smu:
+* smu_set_watermarks_for_clock_ranges
+* smu_set_watermarks_table
+* navi10_set_watermarks_table
+* smu_write_watermarks_table
+*
+* For Renoir, clock settings of dcn watermark are also fixed values.
+* dc has implemented different flow for window driver:
+* dc_hardware_init / dc_set_power_state
+* dcn10_init_hw
+* notify_wm_ranges
+* set_wm_ranges
+* -- Linux
+* smu_set_watermarks_for_clock_ranges
+* renoir_set_watermarks_table
+* smu_write_watermarks_table
+*
+* For Linux,
+* dc_hardware_init -> amdgpu_dm_init
+* dc_set_power_state --> dm_resume
+*
+* therefore, this function apply to navi10/12/14 but not Renoir
+* *
+*/
+   switch(adev->asic_type) {
+   case CHIP_NAVI10:
+   case CHIP_NAVI14:
+   case CHIP_NAVI12:
+   break;
+   default:
+   return 0;
+   }
+
+   /* pass data to smu controller */
+   if ((smu->watermarks_bitmap & WATERMARKS_EXIST) &&
+   !(smu->watermarks_bitmap & WATERMARKS_LOADED)) {
+   ret = smu_write_watermarks_table(smu);
+
+   if (ret) {
+   DRM_ERROR("Failed to update WMTABLE!\n");
+   return ret;
+   }
+   smu->watermarks_bitmap |= WATERMARKS_LOADED;
+   }
+
+   return 0;
+}
+
 /**
  * dm_hw_init() - Initialize DC device
  * @handle: The base driver device containing the amdgpu_dm device.
@@ -1713,6 +1775,8 @@ static int dm_resume(void *handle)
 
amdgpu_dm_irq_resume_late(adev);
 
+   amdgpu_dm_smu_write_watermarks_table(adev);
+
return 0;
 }
 
--
2.17.1

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

[PATCH 2/2] drm/amdgpu: Add debugfs interface to set arbitrary sclk for navi14

[Chengming Gui]

add debugfs interface amdgpu_force_sclk
to set arbitrary sclk for navi14

Signed-off-by: Chengming Gui 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 44 ++
 drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h |  3 ++
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 3bb7405..5ee7e92 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1269,9 +1269,43 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
return 0;
 }
 
+static int amdgpu_debugfs_sclk_set(void *data, u64 val)
+{
+   int ret = 0;
+   uint32_t max_freq, min_freq;
+   struct amdgpu_device *adev = (struct amdgpu_device *)data;
+
+   if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
+   return -EINVAL;
+
+   ret = pm_runtime_get_sync(adev->ddev->dev);
+   if (ret < 0)
+   return ret;
+
+   if (is_support_sw_smu(adev)) {
+   ret = smu_get_dpm_freq_range(>smu, SMU_SCLK, _freq, 
_freq, true);
+   if (ret || val > max_freq || val < min_freq)
+   return -EINVAL;
+   ret = smu_set_soft_freq_range(>smu, SMU_SCLK, 
(uint32_t)val, (uint32_t)val);
+   } else {
+   return 0;
+   }
+
+   pm_runtime_mark_last_busy(adev->ddev->dev);
+   pm_runtime_put_autosuspend(adev->ddev->dev);
+
+   if (ret)
+   return -EINVAL;
+
+   return 0;
+}
+
 DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL,
amdgpu_debugfs_ib_preempt, "%llu\n");
 
+DEFINE_SIMPLE_ATTRIBUTE(fops_sclk_set, NULL,
+   amdgpu_debugfs_sclk_set, "%llu\n");
+
 int amdgpu_debugfs_init(struct amdgpu_device *adev)
 {
int r, i;
@@ -1285,6 +1319,15 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
return -EIO;
}
 
+   adev->smu.debugfs_sclk =
+   debugfs_create_file("amdgpu_force_sclk", 0200,
+   adev->ddev->primary->debugfs_root, adev,
+   _sclk_set);
+   if (!(adev->smu.debugfs_sclk)) {
+   DRM_ERROR("unable to create amdgpu_set_sclk debugsfs file\n");
+   return -EIO;
+   }
+
/* Register debugfs entries for amdgpu_ttm */
r = amdgpu_ttm_debugfs_init(adev);
if (r) {
@@ -1353,6 +1396,7 @@ void amdgpu_debugfs_fini(struct amdgpu_device *adev)
}
amdgpu_ttm_debugfs_fini(adev);
debugfs_remove(adev->debugfs_preempt);
+   debugfs_remove(adev->smu.debugfs_sclk);
 }
 
 #else
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
index 97b6714..36fe19c 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
@@ -371,6 +371,9 @@ struct smu_context
struct amd_pp_display_configuration  *display_config;
struct smu_baco_context smu_baco;
void *od_settings;
+#if defined(CONFIG_DEBUG_FS)
+   struct dentry   *debugfs_sclk;
+#endif
 
uint32_t pstate_sclk;
uint32_t pstate_mclk;
-- 
2.7.4

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

[PATCH 1/2] Revert "drm/amdgpu: add sysfs interface to set arbitrary sclk value for navi14"

[Chengming Gui]

Revert this commit and than add debugfs interface to
replace this to meet the specitic requirement.

This reverts commit 3107269204f8e18f389080673f7848b420970aa5.
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 42 ---
 drivers/gpu/drm/amd/powerplay/smu_v11_0.c |  9 ++-
 2 files changed, 2 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 9deff8c..bc3cf04 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1034,40 +1034,6 @@ static ssize_t amdgpu_read_mask(const char *buf, size_t 
count, uint32_t *mask)
return 0;
 }
 
-static ssize_t amdgpu_set_pp_sclk(struct device *dev,
-   struct device_attribute *attr,
-   const char *buf,
-   size_t count)
-{
-   struct drm_device *ddev = dev_get_drvdata(dev);
-   struct amdgpu_device *adev = ddev->dev_private;
-   int ret;
-   uint32_t value;
-
-   if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
-   return -EINVAL;
-
-   ret = pm_runtime_get_sync(ddev->dev);
-   if (ret < 0)
-   return ret;
-
-   ret = kstrtou32(buf, 0, );
-   if (ret < 0)
-   return ret;
-   if (is_support_sw_smu(adev))
-   ret = smu_set_soft_freq_range(>smu, SMU_SCLK, value, 
value);
-   else
-   return 0;
-
-   pm_runtime_mark_last_busy(ddev->dev);
-   pm_runtime_put_autosuspend(ddev->dev);
-
-   if (ret)
-   return -EINVAL;
-
-   return count;
-}
-
 static ssize_t amdgpu_set_pp_dpm_sclk(struct device *dev,
struct device_attribute *attr,
const char *buf,
@@ -1829,8 +1795,6 @@ static DEVICE_ATTR(pp_force_state, S_IRUGO | S_IWUSR,
 static DEVICE_ATTR(pp_table, S_IRUGO | S_IWUSR,
amdgpu_get_pp_table,
amdgpu_set_pp_table);
-static DEVICE_ATTR(pp_sclk, S_IWUSR,
-   NULL, amdgpu_set_pp_sclk);
 static DEVICE_ATTR(pp_dpm_sclk, S_IRUGO | S_IWUSR,
amdgpu_get_pp_dpm_sclk,
amdgpu_set_pp_dpm_sclk);
@@ -3322,12 +3286,6 @@ int amdgpu_pm_sysfs_init(struct amdgpu_device *adev)
return ret;
}
 
-   ret = device_create_file(adev->dev, _attr_pp_sclk);
-   if (ret) {
-   DRM_ERROR("failed to create device file pp_sclk\n");
-   return ret;
-   }
-
ret = device_create_file(adev->dev, _attr_pp_dpm_sclk);
if (ret) {
DRM_ERROR("failed to create device file pp_dpm_sclk\n");
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c 
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index 1507bb7..c9e5ce1 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -1803,17 +1803,12 @@ int smu_v11_0_set_soft_freq_limited_range(struct 
smu_context *smu, enum smu_clk_
 {
int ret = 0, clk_id = 0;
uint32_t param;
-   uint32_t min_freq, max_freq;
 
clk_id = smu_clk_get_index(smu, clk_type);
if (clk_id < 0)
return clk_id;
 
-   ret = smu_get_dpm_freq_range(smu, clk_type, _freq, _freq, true);
-   if (ret)
-   return ret;
-
-   if (max > 0 && max <=  max_freq) {
+   if (max > 0) {
param = (uint32_t)((clk_id << 16) | (max & 0x));
ret = smu_send_smc_msg_with_param(smu, SMU_MSG_SetSoftMaxByFreq,
  param);
@@ -1821,7 +1816,7 @@ int smu_v11_0_set_soft_freq_limited_range(struct 
smu_context *smu, enum smu_clk_
return ret;
}
 
-   if (min > 0 && min >= min_freq) {
+   if (min > 0) {
param = (uint32_t)((clk_id << 16) | (min & 0x));
ret = smu_send_smc_msg_with_param(smu, SMU_MSG_SetSoftMinByFreq,
  param);
-- 
2.7.4

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

Re: [Mesa-dev] gitlab.fd.o financial situation and impact on services

[Tom Stellard]

On 02/27/2020 05:00 PM, Tom Stellard wrote:
> On 02/27/2020 01:27 PM, Daniel Vetter wrote:
>> Hi all,
>>
>> You might have read the short take in the X.org board meeting minutes
>> already, here's the long version.
>>
>> The good news: gitlab.fd.o has become very popular with our
>> communities, and is used extensively. This especially includes all the
>> CI integration. Modern development process and tooling, yay!
>>
>> The bad news: The cost in growth has also been tremendous, and it's
>> breaking our bank account. With reasonable estimates for continued
>> growth we're expecting hosting expenses totalling 75k USD this year,
>> and 90k USD next year. With the current sponsors we've set up we can't
>> sustain that. We estimate that hosting expenses for gitlab.fd.o
>> without any of the CI features enabled would total 30k USD, which is
>> within X.org's ability to support through various sponsorships, mostly
>> through XDC.
>>
> 
> Have you looked into applying for free credits from amazon:
> 
> https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/
> 

Also fastly provides free CDN services to some Open Source projects:

https://www.fastly.com/open-source?utm_medium=social_source=t.co_campaign=FY17Q4_WebPage_OpenSource

It might also be worth looking into if the main costs are
coming from data transfers.

-Tom

> -Tom
> 
>> Note that X.org does no longer sponsor any CI runners themselves,
>> we've stopped that. The huge additional expenses are all just in
>> storing and serving build artifacts and images to outside CI runners
>> sponsored by various companies. A related topic is that with the
>> growth in fd.o it's becoming infeasible to maintain it all on
>> volunteer admin time. X.org is therefore also looking for admin
>> sponsorship, at least medium term.
>>
>> Assuming that we want cash flow reserves for one year of gitlab.fd.o
>> (without CI support) and a trimmed XDC and assuming no sponsor payment
>> meanwhile, we'd have to cut CI services somewhere between May and June
>> this year. The board is of course working on acquiring sponsors, but
>> filling a shortfall of this magnitude is neither easy nor quick work,
>> and we therefore decided to give an early warning as soon as possible.
>> Any help in finding sponsors for fd.o is very much appreciated.
>>
>> Thanks, Daniel
>>
> 
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

Re: [Mesa-dev] gitlab.fd.o financial situation and impact on services

[Tom Stellard]

On 02/27/2020 01:27 PM, Daniel Vetter wrote:
> Hi all,
> 
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
> 
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
> 
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
> 

Have you looked into applying for free credits from amazon:

https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/

-Tom

> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
> 
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.
> 
> Thanks, Daniel
> 

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

Re: [PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

[Luben Tuikov]

On 2020-02-27 5:10 p.m., Luben Tuikov wrote:
> On 2020-02-27 6:47 a.m., Christian König wrote:
>> Am 27.02.20 um 12:38 schrieb Huang Rui:
>>> Since 6643ba1 frame control packets are only issued in presence of secure 
>>> IB(s).
>>> This causes hangs on some hardware (eg: Raven1). This patch restores the
>>> unconditionnal frame control packets issuing, that's to keep the per-IB 
>>> logic
>>> regarding the secure flag.
>>>
>>> Fixes: 6643ba1 drm/amdgpu: Move to a per-IB secure flag (TMZ)
>>>
>>> v1 -> v2:
>>> As suggested by Luben, and accept part of implemetation from this patch:
>>> - Put "secure" closed to the loop and use optimization
>>> - Change "secure" to bool again, and move "secure == -1" out of loop.
>>>
>>> Reported-and-Tested-by: Pierre-Eric Pelloux-Prayer 
>>> 
>>> Signed-off-by: Huang Rui 
>>> Reviewed-by: Alex Deucher 
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   | 29 
>>> +++--
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  5 +++--
>>>   drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 15 ---
>>>   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 +++--
>>>   4 files changed, 33 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
>>> index 4b2342d..0f4909a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
>>> @@ -216,7 +216,14 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, 
>>> unsigned num_ibs,
>>> amdgpu_ring_emit_cntxcntl(ring, status);
>>> }
>>>   
>>> +   /* Setup initial TMZiness and send it off.
>>> +*/
>>> secure = false;
>>> +   if (job && ring->funcs->emit_frame_cntl) {
>>
>> Does anybody remember why we check the job here in the first place?
> 
> Ring tests do not use a job.
> 
> Having said this, I would've written a separate
> submit for tests and a different one for jobs.
> 
>>
>> Independent of that I think that the check if 
>> ring->funcs->emit_frame_cntl should be moved into the 
>> amdgpu_ring_emit_frame_cntl() function so that we don't need to repeat 
>> that over and over again.
> 
> What if that function is called from a loop? Since it would
> be a static conditional it could be optimized away early on.
> It's a classic optimization pattern.
> 
>>
>> If amdgpu_ring_emit_frame_cntl() is still a macro then that is probably 
>> also a good opportunity to change that.
>>
>>> +   secure = ib->flags & AMDGPU_IB_FLAGS_SECURE ? true : false;

Tim says no need for the ternary here.

>>> +   amdgpu_ring_emit_frame_cntl(ring, true, secure);
>>> +   }
>>> +
>>> for (i = 0; i < num_ibs; ++i) {
>>> ib = [i];
>>>   
>>> @@ -228,27 +235,21 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, 
>>> unsigned num_ibs,
>>> !amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble 
>>> CE ib must be inserted anyway */
>>> continue;
>>>   
>>> -   /* If this IB is TMZ, add frame TMZ start packet,
>>> -* else, turn off TMZ.
>>> -*/
>>> -   if (ib->flags & AMDGPU_IB_FLAGS_SECURE && 
>>> ring->funcs->emit_tmz) {
>>> -   if (!secure) {
>>> -   secure = true;
>>> -   amdgpu_ring_emit_tmz(ring, true);
>>> +   if (job && ring->funcs->emit_frame_cntl) {
>>> +   if (!!secure ^ !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)) {
>>
>> Maybe write this as (secure != !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)). 
>> That is probably easier to understand.
> 
> Thanks! This is indeed better!
> 
> I'll resubmit with your suggestions and another good one from Tim.

Sorry, I thought this was a comment on my patch as the expression was taken
right out of it.

>>
>>> +   amdgpu_ring_emit_frame_cntl(ring, false, 
>>> secure);
>>> +   secure = !secure;
>>> +   amdgpu_ring_emit_frame_cntl(ring, true, secure);
>>> }
>>> -   } else if (secure) {
>>> -   secure = false;
>>> -   amdgpu_ring_emit_tmz(ring, false);
>>> }
>>>   
>>> amdgpu_ring_emit_ib(ring, job, ib, status);
>>> status &= ~AMDGPU_HAVE_CTX_SWITCH;
>>> }
>>>   
>>> -   if (secure) {
>>> -   secure = false;
>>> -   amdgpu_ring_emit_tmz(ring, false);
>>> -   }
>>> +   if (job && ring->funcs->emit_frame_cntl)
>>> +   amdgpu_ring_emit_frame_cntl(ring, false,
>>> +   secure ? true : false);

"secure" is already a boolean.

Regards,
Luben


>>>   
>>>   #ifdef CONFIG_X86_64
>>> if (!(adev->flags & AMD_IS_APU))
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
>>> index 24caff0..4d019d6 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
>>> +++ 

Re: gitlab.fd.o financial situation and impact on services

[Luc Verhaegen]

On Thu, Feb 27, 2020 at 10:27:04PM +0100, Daniel Vetter wrote:
> Hi all,
> 
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
> 
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
> 
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
> 
> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
> 
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.
> 
> Thanks, Daniel

So this cost is all about fd.o?

I feel that this was not communicated to x.org members at all, when fd.o 
"merging" was suggested. In as far as this was a merge.

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

Re: gitlab.fd.o financial situation and impact on services

[Matt Turner]

On Thu, Feb 27, 2020 at 1:27 PM Daniel Vetter  wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
>
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
>
> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
>
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.

Some clarification I got from Daniel in a private conversation, since
I was confused about what the money was paying for exactly:

We're paying 75K USD for the bandwidth to transfer data from the
GitLab cloud instance. i.e., for viewing the https site, for
cloning/updating git repos, and for downloading CI artifacts/images to
the testing machines (AFAIU).

I was not aware that we were being charged for anything wrt GitLab
hosting yet (and neither was anyone on my team at Intel that I've
asked). This... kind of needs to be communicated.

A consistent concern put forth when we were discussing switching to
GitLab and building CI was... how do we pay for it. It felt like that
concern was always handwaved away. I heard many times that if we
needed more runners that we could just ask Google to spin up a few
more. If we needed testing machines they'd be donated. No one
mentioned that all the while we were paying for bandwidth... Perhaps
people building the CI would make different decisions about its
structure if they knew it was going to wipe out the bank account.

What percentage of the bandwidth is consumed by transferring CI
images, etc? Wouldn't 75K USD would be enough to buy all the testing
machines we need and host them within Google or wherever so we don't
need to pay for huge amounts of bandwidth?

I understand that self-hosting was attractive so that we didn't find
ourselves on the SourceForge-equivalent hosting platform of 2022, but
is that risk real enough to justify spending 75K+ per year? If we were
hosted on gitlab.com or github.com, we wouldn't be paying for
transferring CI images to CI test machines, etc, would we?

So what do we do now? Have we painted ourselves into a corner?
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

[Luben Tuikov]

On 2020-02-27 6:47 a.m., Christian König wrote:
> Am 27.02.20 um 12:38 schrieb Huang Rui:
>> Since 6643ba1 frame control packets are only issued in presence of secure 
>> IB(s).
>> This causes hangs on some hardware (eg: Raven1). This patch restores the
>> unconditionnal frame control packets issuing, that's to keep the per-IB logic
>> regarding the secure flag.
>>
>> Fixes: 6643ba1 drm/amdgpu: Move to a per-IB secure flag (TMZ)
>>
>> v1 -> v2:
>> As suggested by Luben, and accept part of implemetation from this patch:
>> - Put "secure" closed to the loop and use optimization
>> - Change "secure" to bool again, and move "secure == -1" out of loop.
>>
>> Reported-and-Tested-by: Pierre-Eric Pelloux-Prayer 
>> 
>> Signed-off-by: Huang Rui 
>> Reviewed-by: Alex Deucher 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   | 29 +++--
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  5 +++--
>>   drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 15 ---
>>   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 +++--
>>   4 files changed, 33 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
>> index 4b2342d..0f4909a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
>> @@ -216,7 +216,14 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, 
>> unsigned num_ibs,
>>  amdgpu_ring_emit_cntxcntl(ring, status);
>>  }
>>   
>> +/* Setup initial TMZiness and send it off.
>> + */
>>  secure = false;
>> +if (job && ring->funcs->emit_frame_cntl) {
> 
> Does anybody remember why we check the job here in the first place?

Ring tests do not use a job.

Having said this, I would've written a separate
submit for tests and a different one for jobs.

> 
> Independent of that I think that the check if 
> ring->funcs->emit_frame_cntl should be moved into the 
> amdgpu_ring_emit_frame_cntl() function so that we don't need to repeat 
> that over and over again.

What if that function is called from a loop? Since it would
be a static conditional it could be optimized away early on.
It's a classic optimization pattern.

> 
> If amdgpu_ring_emit_frame_cntl() is still a macro then that is probably 
> also a good opportunity to change that.
> 
>> +secure = ib->flags & AMDGPU_IB_FLAGS_SECURE ? true : false;
>> +amdgpu_ring_emit_frame_cntl(ring, true, secure);
>> +}
>> +
>>  for (i = 0; i < num_ibs; ++i) {
>>  ib = [i];
>>   
>> @@ -228,27 +235,21 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, 
>> unsigned num_ibs,
>>  !amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble 
>> CE ib must be inserted anyway */
>>  continue;
>>   
>> -/* If this IB is TMZ, add frame TMZ start packet,
>> - * else, turn off TMZ.
>> - */
>> -if (ib->flags & AMDGPU_IB_FLAGS_SECURE && 
>> ring->funcs->emit_tmz) {
>> -if (!secure) {
>> -secure = true;
>> -amdgpu_ring_emit_tmz(ring, true);
>> +if (job && ring->funcs->emit_frame_cntl) {
>> +if (!!secure ^ !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)) {
> 
> Maybe write this as (secure != !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)). 
> That is probably easier to understand.

Thanks! This is indeed better!

I'll resubmit with your suggestions and another good one from Tim.

Regards,
Luben


> 
> Regards,
> Christian.
> 
>> +amdgpu_ring_emit_frame_cntl(ring, false, 
>> secure);
>> +secure = !secure;
>> +amdgpu_ring_emit_frame_cntl(ring, true, secure);
>>  }
>> -} else if (secure) {
>> -secure = false;
>> -amdgpu_ring_emit_tmz(ring, false);
>>  }
>>   
>>  amdgpu_ring_emit_ib(ring, job, ib, status);
>>  status &= ~AMDGPU_HAVE_CTX_SWITCH;
>>  }
>>   
>> -if (secure) {
>> -secure = false;
>> -amdgpu_ring_emit_tmz(ring, false);
>> -}
>> +if (job && ring->funcs->emit_frame_cntl)
>> +amdgpu_ring_emit_frame_cntl(ring, false,
>> +secure ? true : false);
>>   
>>   #ifdef CONFIG_X86_64
>>  if (!(adev->flags & AMD_IS_APU))
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
>> index 24caff0..4d019d6 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
>> @@ -166,7 +166,8 @@ struct amdgpu_ring_funcs {
>>  void (*emit_reg_write_reg_wait)(struct amdgpu_ring *ring,
>>  uint32_t reg0, uint32_t reg1,
>>  uint32_t ref, uint32_t mask);
>> -void 

Re: [RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

[Das, Nirmoy]

[AMD Official Use Only - Internal Distribution Only]

Yes I missed gfx_v10_0.c. I will resend a updated one tomorrow.

Regards,
Nirmoy
Get Outlook for Android

From: Alex Deucher 
Sent: Thursday, February 27, 2020 10:50:35 PM
To: Nirmoy Das 
Cc: amd-gfx list ; Deucher, Alexander 
; Huang, Ray ; Das, Nirmoy 
; Koenig, Christian 
Subject: Re: [RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

On Thu, Feb 27, 2020 at 4:48 PM Alex Deucher  wrote:
>
> On Thu, Feb 27, 2020 at 4:37 PM Nirmoy Das  wrote:
> >
> > We were changing compute ring priority while rings were being used
> > before every job submission which is not recommended. This patch
> > sets compute queue priority at mqd initialization for gfx8 and gfx9.
> >
> > Policy: Enable high priority compute queues only if gpu has >1 MEC, if
> > so PIPE0 and PIPE1 will be in high priority.
>
> I think we still want high priority queues on even when there is only
> one MEC.  It might work better on multi-MEC chips, but it should still
> work on single MEC chips.
>
> >
> > high/normal priority compute sched list are generated from set of 
> > high/normal
> > priority compute queues. At context creation, entity of compute queue
> > get a sched list from high or normal priority depending on ctx->priority
> >
> > Signed-off-by: Nirmoy Das 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  4 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 19 +++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c  | 14 ++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h  | 12 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  6 --
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 23 ---
> >  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 20 

Also, can you add a patch for gfx_v10_0.c?

Alex

> >  8 files changed, 82 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index f397ff97b4e4..8304d0c87899 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -1205,7 +1205,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser 
> > *p,
> > struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> > struct drm_sched_entity *entity = p->entity;
> > enum drm_sched_priority priority;
> > -   struct amdgpu_ring *ring;
> > struct amdgpu_bo_list_entry *e;
> > struct amdgpu_job *job;
> > uint64_t seq;
> > @@ -1258,9 +1257,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser 
> > *p,
> > priority = job->base.s_priority;
> > drm_sched_entity_push_job(>base, entity);
> >
> > -   ring = to_amdgpu_ring(entity->rq->sched);
> > -   amdgpu_ring_priority_get(ring, priority);
> > -
> > amdgpu_vm_move_to_lru_tail(p->adev, >vm);
> >
> > ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > index 94a6c42f29ea..a1742b1d4f9c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > @@ -85,8 +85,14 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx 
> > *ctx, const u32 hw_ip, const
> > num_scheds = 1;
> > break;
> > case AMDGPU_HW_IP_COMPUTE:
> > -   scheds = adev->gfx.compute_sched;
> > -   num_scheds = adev->gfx.num_compute_sched;
> > +   if (priority > DRM_SCHED_PRIORITY_NORMAL &&
> > +   adev->gfx.num_compute_sched_high) {
> > +   scheds = adev->gfx.compute_sched_high;
> > +   num_scheds = 
> > adev->gfx.num_compute_sched_high;
> > +   } else {
> > +   scheds = adev->gfx.compute_sched;
> > +   num_scheds = adev->gfx.num_compute_sched;
> > +   }
> > break;
> > case AMDGPU_HW_IP_DMA:
> > scheds = adev->sdma.sdma_sched;
> > @@ -638,8 +644,13 @@ void amdgpu_ctx_init_sched(struct amdgpu_device *adev)
> > }
> >
> > for (i = 0; i < adev->gfx.num_compute_rings; i++) {
> > -   adev->gfx.compute_sched[i] = 
> > >gfx.compute_ring[i].sched;
> > -   adev->gfx.num_compute_sched++;
> > +   if (!adev->gfx.compute_ring[i].high_priority) {
> > +   
> > adev->gfx.compute_sched[adev->gfx.num_compute_sched++] =
> > +   >gfx.compute_ring[i].sched;
> > +   } else {
> > +   
> > adev->gfx.compute_sched_high[adev->gfx.num_compute_sched_high++] =

Re: [RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

[Alex Deucher]

On Thu, Feb 27, 2020 at 4:48 PM Alex Deucher  wrote:
>
> On Thu, Feb 27, 2020 at 4:37 PM Nirmoy Das  wrote:
> >
> > We were changing compute ring priority while rings were being used
> > before every job submission which is not recommended. This patch
> > sets compute queue priority at mqd initialization for gfx8 and gfx9.
> >
> > Policy: Enable high priority compute queues only if gpu has >1 MEC, if
> > so PIPE0 and PIPE1 will be in high priority.
>
> I think we still want high priority queues on even when there is only
> one MEC.  It might work better on multi-MEC chips, but it should still
> work on single MEC chips.
>
> >
> > high/normal priority compute sched list are generated from set of 
> > high/normal
> > priority compute queues. At context creation, entity of compute queue
> > get a sched list from high or normal priority depending on ctx->priority
> >
> > Signed-off-by: Nirmoy Das 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  4 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 19 +++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c  | 14 ++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h  | 12 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  6 --
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 23 ---
> >  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 20 

Also, can you add a patch for gfx_v10_0.c?

Alex

> >  8 files changed, 82 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index f397ff97b4e4..8304d0c87899 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -1205,7 +1205,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser 
> > *p,
> > struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> > struct drm_sched_entity *entity = p->entity;
> > enum drm_sched_priority priority;
> > -   struct amdgpu_ring *ring;
> > struct amdgpu_bo_list_entry *e;
> > struct amdgpu_job *job;
> > uint64_t seq;
> > @@ -1258,9 +1257,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser 
> > *p,
> > priority = job->base.s_priority;
> > drm_sched_entity_push_job(>base, entity);
> >
> > -   ring = to_amdgpu_ring(entity->rq->sched);
> > -   amdgpu_ring_priority_get(ring, priority);
> > -
> > amdgpu_vm_move_to_lru_tail(p->adev, >vm);
> >
> > ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > index 94a6c42f29ea..a1742b1d4f9c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > @@ -85,8 +85,14 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx 
> > *ctx, const u32 hw_ip, const
> > num_scheds = 1;
> > break;
> > case AMDGPU_HW_IP_COMPUTE:
> > -   scheds = adev->gfx.compute_sched;
> > -   num_scheds = adev->gfx.num_compute_sched;
> > +   if (priority > DRM_SCHED_PRIORITY_NORMAL &&
> > +   adev->gfx.num_compute_sched_high) {
> > +   scheds = adev->gfx.compute_sched_high;
> > +   num_scheds = 
> > adev->gfx.num_compute_sched_high;
> > +   } else {
> > +   scheds = adev->gfx.compute_sched;
> > +   num_scheds = adev->gfx.num_compute_sched;
> > +   }
> > break;
> > case AMDGPU_HW_IP_DMA:
> > scheds = adev->sdma.sdma_sched;
> > @@ -638,8 +644,13 @@ void amdgpu_ctx_init_sched(struct amdgpu_device *adev)
> > }
> >
> > for (i = 0; i < adev->gfx.num_compute_rings; i++) {
> > -   adev->gfx.compute_sched[i] = 
> > >gfx.compute_ring[i].sched;
> > -   adev->gfx.num_compute_sched++;
> > +   if (!adev->gfx.compute_ring[i].high_priority) {
> > +   
> > adev->gfx.compute_sched[adev->gfx.num_compute_sched++] =
> > +   >gfx.compute_ring[i].sched;
> > +   } else {
> > +   
> > adev->gfx.compute_sched_high[adev->gfx.num_compute_sched_high++] =
> > +   >gfx.compute_ring[i].sched;
> > +   }
> > }
> >
> > for (i = 0; i < adev->sdma.num_instances; i++) {
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> > index 7403588684b3..bdea5d44edf4 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> > @@ -192,6 +192,20 @@ static bool 

Re: [RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

[Alex Deucher]

On Thu, Feb 27, 2020 at 4:37 PM Nirmoy Das  wrote:
>
> We were changing compute ring priority while rings were being used
> before every job submission which is not recommended. This patch
> sets compute queue priority at mqd initialization for gfx8 and gfx9.
>
> Policy: Enable high priority compute queues only if gpu has >1 MEC, if
> so PIPE0 and PIPE1 will be in high priority.

I think we still want high priority queues on even when there is only
one MEC.  It might work better on multi-MEC chips, but it should still
work on single MEC chips.

>
> high/normal priority compute sched list are generated from set of high/normal
> priority compute queues. At context creation, entity of compute queue
> get a sched list from high or normal priority depending on ctx->priority
>
> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  4 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 19 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c  | 14 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h  | 12 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  6 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 23 ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 20 
>  8 files changed, 82 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index f397ff97b4e4..8304d0c87899 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -1205,7 +1205,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
> struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> struct drm_sched_entity *entity = p->entity;
> enum drm_sched_priority priority;
> -   struct amdgpu_ring *ring;
> struct amdgpu_bo_list_entry *e;
> struct amdgpu_job *job;
> uint64_t seq;
> @@ -1258,9 +1257,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
> priority = job->base.s_priority;
> drm_sched_entity_push_job(>base, entity);
>
> -   ring = to_amdgpu_ring(entity->rq->sched);
> -   amdgpu_ring_priority_get(ring, priority);
> -
> amdgpu_vm_move_to_lru_tail(p->adev, >vm);
>
> ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> index 94a6c42f29ea..a1742b1d4f9c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> @@ -85,8 +85,14 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, 
> const u32 hw_ip, const
> num_scheds = 1;
> break;
> case AMDGPU_HW_IP_COMPUTE:
> -   scheds = adev->gfx.compute_sched;
> -   num_scheds = adev->gfx.num_compute_sched;
> +   if (priority > DRM_SCHED_PRIORITY_NORMAL &&
> +   adev->gfx.num_compute_sched_high) {
> +   scheds = adev->gfx.compute_sched_high;
> +   num_scheds = adev->gfx.num_compute_sched_high;
> +   } else {
> +   scheds = adev->gfx.compute_sched;
> +   num_scheds = adev->gfx.num_compute_sched;
> +   }
> break;
> case AMDGPU_HW_IP_DMA:
> scheds = adev->sdma.sdma_sched;
> @@ -638,8 +644,13 @@ void amdgpu_ctx_init_sched(struct amdgpu_device *adev)
> }
>
> for (i = 0; i < adev->gfx.num_compute_rings; i++) {
> -   adev->gfx.compute_sched[i] = >gfx.compute_ring[i].sched;
> -   adev->gfx.num_compute_sched++;
> +   if (!adev->gfx.compute_ring[i].high_priority) {
> +   
> adev->gfx.compute_sched[adev->gfx.num_compute_sched++] =
> +   >gfx.compute_ring[i].sched;
> +   } else {
> +   
> adev->gfx.compute_sched_high[adev->gfx.num_compute_sched_high++] =
> +   >gfx.compute_ring[i].sched;
> +   }
> }
>
> for (i = 0; i < adev->sdma.num_instances; i++) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index 7403588684b3..bdea5d44edf4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -192,6 +192,20 @@ static bool amdgpu_gfx_is_multipipe_capable(struct 
> amdgpu_device *adev)
> return adev->gfx.mec.num_mec > 1;
>  }
>
> +bool amdgpu_gfx_is_high_priority_compute_queue(struct amdgpu_device *adev,
> +  int queue)
> +{
> +   bool multipipe_policy = amdgpu_gfx_is_multipipe_capable(adev);
> +
> +   

Re: [RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

[Nirmoy]

On 2/27/20 10:40 PM, Nirmoy Das wrote:

We were changing compute ring priority while rings were being used
before every job submission which is not recommended. This patch
sets compute queue priority at mqd initialization for gfx8 and gfx9.

Policy: Enable high priority compute queues only if gpu has >1 MEC, if
so PIPE0 and PIPE1 will be in high priority.
s/PIPE0 and PIPE1 will be in high priority/ 1st queue of each pipe will 
set to high priority

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

[RFC PATCH 1/4] drm/amdgpu: set compute queue priority at mqd_init

[Nirmoy Das]

We were changing compute ring priority while rings were being used
before every job submission which is not recommended. This patch
sets compute queue priority at mqd initialization for gfx8 and gfx9.

Policy: Enable high priority compute queues only if gpu has >1 MEC, if
so PIPE0 and PIPE1 will be in high priority.

high/normal priority compute sched list are generated from set of high/normal
priority compute queues. At context creation, entity of compute queue
get a sched list from high or normal priority depending on ctx->priority

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 19 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c  | 14 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h  | 12 
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  6 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 23 ---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 20 
 8 files changed, 82 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index f397ff97b4e4..8304d0c87899 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1205,7 +1205,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
struct drm_sched_entity *entity = p->entity;
enum drm_sched_priority priority;
-   struct amdgpu_ring *ring;
struct amdgpu_bo_list_entry *e;
struct amdgpu_job *job;
uint64_t seq;
@@ -1258,9 +1257,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
priority = job->base.s_priority;
drm_sched_entity_push_job(>base, entity);
 
-   ring = to_amdgpu_ring(entity->rq->sched);
-   amdgpu_ring_priority_get(ring, priority);
-
amdgpu_vm_move_to_lru_tail(p->adev, >vm);
 
ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 94a6c42f29ea..a1742b1d4f9c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -85,8 +85,14 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, 
const u32 hw_ip, const
num_scheds = 1;
break;
case AMDGPU_HW_IP_COMPUTE:
-   scheds = adev->gfx.compute_sched;
-   num_scheds = adev->gfx.num_compute_sched;
+   if (priority > DRM_SCHED_PRIORITY_NORMAL &&
+   adev->gfx.num_compute_sched_high) {
+   scheds = adev->gfx.compute_sched_high;
+   num_scheds = adev->gfx.num_compute_sched_high;
+   } else {
+   scheds = adev->gfx.compute_sched;
+   num_scheds = adev->gfx.num_compute_sched;
+   }
break;
case AMDGPU_HW_IP_DMA:
scheds = adev->sdma.sdma_sched;
@@ -638,8 +644,13 @@ void amdgpu_ctx_init_sched(struct amdgpu_device *adev)
}
 
for (i = 0; i < adev->gfx.num_compute_rings; i++) {
-   adev->gfx.compute_sched[i] = >gfx.compute_ring[i].sched;
-   adev->gfx.num_compute_sched++;
+   if (!adev->gfx.compute_ring[i].high_priority) {
+   adev->gfx.compute_sched[adev->gfx.num_compute_sched++] =
+   >gfx.compute_ring[i].sched;
+   } else {
+   
adev->gfx.compute_sched_high[adev->gfx.num_compute_sched_high++] =
+   >gfx.compute_ring[i].sched;
+   }
}
 
for (i = 0; i < adev->sdma.num_instances; i++) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index 7403588684b3..bdea5d44edf4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -192,6 +192,20 @@ static bool amdgpu_gfx_is_multipipe_capable(struct 
amdgpu_device *adev)
return adev->gfx.mec.num_mec > 1;
 }
 
+bool amdgpu_gfx_is_high_priority_compute_queue(struct amdgpu_device *adev,
+  int queue)
+{
+   bool multipipe_policy = amdgpu_gfx_is_multipipe_capable(adev);
+
+   /* only enable high priority queue if more than 1 MEC.
+* When multipipe_policy is true amdgpu gets queue 0,1 from each pipe of
+* 1st MEC. Policy: make queue 0 of each pipe as high priority compute 
queue */
+   if (multipipe_policy && queue == 0)
+   return true;
+
+   return false;
+}
+
 void amdgpu_gfx_compute_queue_acquire(struct amdgpu_device *adev)
 {
int i, 

[RFC PATCH 4/4] drm/amdgpu: remove unused functions

[Nirmoy Das]

amdgpu statically set priority for compute queues
at initialization so remove all the functions
responsible changing compute queue priority dynamically

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c |  70 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |   7 --
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c|  99 --
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 100 ---
 4 files changed, 276 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index 18e11b0fdc3e..4d603ee72b8c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -150,76 +150,6 @@ void amdgpu_ring_undo(struct amdgpu_ring *ring)
ring->funcs->end_use(ring);
 }
 
-/**
- * amdgpu_ring_priority_put - restore a ring's priority
- *
- * @ring: amdgpu_ring structure holding the information
- * @priority: target priority
- *
- * Release a request for executing at @priority
- */
-void amdgpu_ring_priority_put(struct amdgpu_ring *ring,
- enum drm_sched_priority priority)
-{
-   int i;
-
-   if (!ring->funcs->set_priority)
-   return;
-
-   if (atomic_dec_return(>num_jobs[priority]) > 0)
-   return;
-
-   /* no need to restore if the job is already at the lowest priority */
-   if (priority == DRM_SCHED_PRIORITY_NORMAL)
-   return;
-
-   mutex_lock(>priority_mutex);
-   /* something higher prio is executing, no need to decay */
-   if (ring->priority > priority)
-   goto out_unlock;
-
-   /* decay priority to the next level with a job available */
-   for (i = priority; i >= DRM_SCHED_PRIORITY_MIN; i--) {
-   if (i == DRM_SCHED_PRIORITY_NORMAL
-   || atomic_read(>num_jobs[i])) {
-   ring->priority = i;
-   ring->funcs->set_priority(ring, i);
-   break;
-   }
-   }
-
-out_unlock:
-   mutex_unlock(>priority_mutex);
-}
-
-/**
- * amdgpu_ring_priority_get - change the ring's priority
- *
- * @ring: amdgpu_ring structure holding the information
- * @priority: target priority
- *
- * Request a ring's priority to be raised to @priority (refcounted).
- */
-void amdgpu_ring_priority_get(struct amdgpu_ring *ring,
- enum drm_sched_priority priority)
-{
-   if (!ring->funcs->set_priority)
-   return;
-
-   if (atomic_inc_return(>num_jobs[priority]) <= 0)
-   return;
-
-   mutex_lock(>priority_mutex);
-   if (priority <= ring->priority)
-   goto out_unlock;
-
-   ring->priority = priority;
-   ring->funcs->set_priority(ring, priority);
-
-out_unlock:
-   mutex_unlock(>priority_mutex);
-}
-
 /**
  * amdgpu_ring_init - init driver ring struct.
  *
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 34fcd467f18d..87ec35b68bfd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -167,9 +167,6 @@ struct amdgpu_ring_funcs {
uint32_t reg0, uint32_t reg1,
uint32_t ref, uint32_t mask);
void (*emit_tmz)(struct amdgpu_ring *ring, bool start);
-   /* priority functions */
-   void (*set_priority) (struct amdgpu_ring *ring,
- enum drm_sched_priority priority);
/* Try to soft recover the ring to make the fence signal */
void (*soft_recovery)(struct amdgpu_ring *ring, unsigned vmid);
int (*preempt_ib)(struct amdgpu_ring *ring);
@@ -259,10 +256,6 @@ void amdgpu_ring_insert_nop(struct amdgpu_ring *ring, 
uint32_t count);
 void amdgpu_ring_generic_pad_ib(struct amdgpu_ring *ring, struct amdgpu_ib 
*ib);
 void amdgpu_ring_commit(struct amdgpu_ring *ring);
 void amdgpu_ring_undo(struct amdgpu_ring *ring);
-void amdgpu_ring_priority_get(struct amdgpu_ring *ring,
- enum drm_sched_priority priority);
-void amdgpu_ring_priority_put(struct amdgpu_ring *ring,
- enum drm_sched_priority priority);
 int amdgpu_ring_init(struct amdgpu_device *adev, struct amdgpu_ring *ring,
 unsigned ring_size, struct amdgpu_irq_src *irq_src,
 unsigned irq_type);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 4260becd569b..3cd9e77c66eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -6258,104 +6258,6 @@ static void gfx_v8_0_ring_set_wptr_compute(struct 
amdgpu_ring *ring)
WDOORBELL32(ring->doorbell_index, lower_32_bits(ring->wptr));
 }
 
-static void gfx_v8_0_ring_set_pipe_percent(struct amdgpu_ring *ring,
-  

[RFC PATCH 2/4] drm/scheduler: implement a function to modify sched list

[Nirmoy Das]

implement drm_sched_entity_modify_sched() which can modify existing
sched_list with a different one. This is going to be helpful when
userspace changes priority of a ctx/entity then driver can switch to
corresponding hw shced list for that priority

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/scheduler/sched_entity.c | 24 
 include/drm/gpu_scheduler.h  |  4 
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
b/drivers/gpu/drm/scheduler/sched_entity.c
index 63bccd201b97..711e9d504bcb 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -83,6 +83,30 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
 }
 EXPORT_SYMBOL(drm_sched_entity_init);
 
+/**
+ * drm_sched_entity_modify_sched - Modify sched of an entity
+ *
+ * @entity: scheduler entity to init
+ * @sched_list: the list of new drm scheds which will replace
+ * existing entity->sched_list
+ * @num_sched_list: number of drm sched in sched_list
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
+ struct drm_gpu_scheduler **sched_list,
+ unsigned int num_sched_list)
+{
+   if (!(entity && sched_list && (num_sched_list == 0 || sched_list[0])))
+   return -EINVAL;
+
+   entity->sched_list = num_sched_list > 1 ? sched_list : NULL;
+   entity->num_sched_list = num_sched_list;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_sched_entity_modify_sched);
+
 /**
  * drm_sched_entity_is_idle - Check if entity is idle
  *
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 589be851f8a1..0c164a96d51b 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -297,6 +297,10 @@ void drm_sched_fini(struct drm_gpu_scheduler *sched);
 int drm_sched_job_init(struct drm_sched_job *job,
   struct drm_sched_entity *entity,
   void *owner);
+int drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
+ struct drm_gpu_scheduler **sched_list,
+  unsigned int num_sched_list);
+
 void drm_sched_job_cleanup(struct drm_sched_job *job);
 void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
 void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job 
*bad);
-- 
2.25.0

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

[RFC PATCH 3/4] drm/amdgpu: change hw sched list on ctx priority override

[Nirmoy Das]

Switch to appropriate sched list for an entity on priority override.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 54 -
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index a1742b1d4f9c..69a791430b25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -508,11 +508,53 @@ struct dma_fence *amdgpu_ctx_get_fence(struct amdgpu_ctx 
*ctx,
return fence;
 }
 
+static int amdgpu_ctx_change_sched(struct amdgpu_ctx *ctx,
+  struct amdgpu_ctx_entity *aentity,
+  int hw_ip, enum drm_sched_priority priority)
+{
+   struct amdgpu_device *adev = ctx->adev;
+   struct drm_gpu_scheduler **scheds = NULL;
+   unsigned num_scheds = 0;
+
+   switch (hw_ip) {
+   case AMDGPU_HW_IP_COMPUTE:
+   if (priority > DRM_SCHED_PRIORITY_NORMAL &&
+   adev->gfx.num_compute_sched_high) {
+   scheds = adev->gfx.compute_sched_high;
+   num_scheds = adev->gfx.num_compute_sched_high;
+   } else {
+   scheds = adev->gfx.compute_sched;
+   num_scheds = adev->gfx.num_compute_sched;
+   }
+   break;
+   default:
+   return 0;
+   }
+
+   return drm_sched_entity_modify_sched(>entity, scheds, 
num_scheds);
+}
+
+static int amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx,
+   const u32 hw_ip,
+   enum drm_sched_priority priority)
+{
+   int r = 0, i;
+
+   for (i = 0; i < amdgpu_ctx_num_entities[hw_ip]; ++i) {
+   if (!ctx->entities[hw_ip][i])
+   continue;
+   r = amdgpu_ctx_change_sched(ctx, ctx->entities[hw_ip][i],
+   hw_ip, priority);
+   }
+
+   return r;
+}
+
 void amdgpu_ctx_priority_override(struct amdgpu_ctx *ctx,
  enum drm_sched_priority priority)
 {
enum drm_sched_priority ctx_prio;
-   unsigned i, j;
+   unsigned r, i, j;
 
ctx->override_priority = priority;
 
@@ -521,11 +563,21 @@ void amdgpu_ctx_priority_override(struct amdgpu_ctx *ctx,
for (i = 0; i < AMDGPU_HW_IP_NUM; ++i) {
for (j = 0; j < amdgpu_ctx_num_entities[i]; ++j) {
struct drm_sched_entity *entity;
+   struct amdgpu_ring *ring;
 
if (!ctx->entities[i][j])
continue;
 
entity = >entities[i][j]->entity;
+   ring = to_amdgpu_ring(entity->rq->sched);
+
+   if (ring->high_priority) {
+   r = amdgpu_ctx_hw_priority_override(ctx, i,
+   ctx_prio);
+   if (r)
+   DRM_ERROR("Failed to override HW 
priority for %s",
+ ring->name);
+   }
drm_sched_entity_set_priority(entity, ctx_prio);
}
}
-- 
2.25.0

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

Re: [PATCH 1/1] drm/amdgpu: Fix per-IB secure flag GFX hang

[Alex Deucher]

On Thu, Feb 27, 2020 at 4:15 PM Luben Tuikov  wrote:
>
> On 2020-02-27 6:56 a.m., Huang Rui wrote:
> > On Thu, Feb 27, 2020 at 06:39:03AM +0800, Tuikov, Luben wrote:
> >> Since commit "Move to a per-IB secure flag (TMZ)",
> >> we've been seeing hangs in GFX. Ray H. pointed out
> >> by sending a patch that we need to send FRAME
> >> CONTROL stop/start back-to-back, every time we
> >> flip the TMZ flag as per each IB we submit. That
> >> is, when we transition from TMZ to non-TMZ we have
> >> to send a stop with TMZ followed by a start with
> >> non-TMZ, and similarly for transitioning from
> >> non-TMZ into TMZ.
> >>
> >> This patch implements this, thus fixing the GFX
> >> hang.
> >>
> >> Signed-off-by: Luben Tuikov 
> >> ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   | 87 +---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  5 +-
> >>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 15 ++--
> >>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 ++--
> >>  4 files changed, 79 insertions(+), 41 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> >> index 4b2342d11520..16d6df3304d3 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> >> @@ -216,40 +216,75 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, 
> >> unsigned num_ibs,
> >>  amdgpu_ring_emit_cntxcntl(ring, status);
> >>  }
> >>
> >> -secure = false;
> >> +/* Find the first non-preamble IB.
> >> + */
> >>  for (i = 0; i < num_ibs; ++i) {
> >>  ib = [i];
> >>
> >>  /* drop preamble IBs if we don't have a context switch */
> >> -if ((ib->flags & AMDGPU_IB_FLAG_PREAMBLE) &&
> >> -skip_preamble &&
> >> -!(status & AMDGPU_PREAMBLE_IB_PRESENT_FIRST) &&
> >> -!amdgpu_mcbp &&
> >> -!amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble 
> >> CE ib must be inserted anyway */
> >> -continue;
> >> -
> >> -/* If this IB is TMZ, add frame TMZ start packet,
> >> - * else, turn off TMZ.
> >> - */
> >> -if (ib->flags & AMDGPU_IB_FLAGS_SECURE && 
> >> ring->funcs->emit_tmz) {
> >> -if (!secure) {
> >> -secure = true;
> >> -amdgpu_ring_emit_tmz(ring, true);
> >> -}
> >> -} else if (secure) {
> >> +if (!(ib->flags & AMDGPU_IB_FLAG_PREAMBLE) ||
> >> +!skip_preamble ||
> >> +(status & AMDGPU_PREAMBLE_IB_PRESENT_FIRST) ||
> >> +amdgpu_mcbp ||
> >> +amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble 
> >> CE ib must be inserted anyway */
> >> +break;
> >> +}
> >> +if (i >= num_ibs)
> >> +goto Done;
> >> +/* Setup initial TMZiness and send it off.
> >> + */
> >> +secure = false;
> >> +if (job && ring->funcs->emit_frame_cntl) {
> >> +if (ib->flags & AMDGPU_IB_FLAGS_SECURE)
> >> +secure = true;
> >> +else
> >>  secure = false;
> >> -amdgpu_ring_emit_tmz(ring, false);
> >> -}
> >> -
> >> -amdgpu_ring_emit_ib(ring, job, ib, status);
> >> -status &= ~AMDGPU_HAVE_CTX_SWITCH;
> >> +amdgpu_ring_emit_frame_cntl(ring, true, secure);
> >>  }
> >> +amdgpu_ring_emit_ib(ring, job, ib, status);
> >> +status &= ~AMDGPU_HAVE_CTX_SWITCH;
> >> +i += 1;
> >> +/* Send the rest of the IBs.
> >> + */
> >> +if (job && ring->funcs->emit_frame_cntl) {
> >> +for ( ; i < num_ibs; ++i) {
> >> +ib = [i];
> >> +
> >> +/* drop preamble IBs if we don't have a context 
> >> switch */
> >> +if ((ib->flags & AMDGPU_IB_FLAG_PREAMBLE) &&
> >> +skip_preamble &&
> >> +!(status & AMDGPU_PREAMBLE_IB_PRESENT_FIRST) &&
> >> +!amdgpu_mcbp &&
> >> +!amdgpu_sriov_vf(adev)) /* for SRIOV preemption, 
> >> Preamble CE ib must be inserted anyway */
> >> +continue;
> >
> > Snip.
> >
> >> +
> >> +if (!!secure ^ !!(ib->flags & 
> >> AMDGPU_IB_FLAGS_SECURE)) {
> >> +amdgpu_ring_emit_frame_cntl(ring, false, 
> >> secure);
> >> +secure = !secure;
> >> +amdgpu_ring_emit_frame_cntl(ring, true, 
> >> secure);
> >> +}
> >
> > That's pretty good optimization! I spend quit a few time to understand this.
>
> I know. I know you did. It's called experience.
>
> When I saw you v1, it was a cringe. Seriously?

It may be a good optimization but if it's hard to understand it makes
the 

gitlab.fd.o financial situation and impact on services

[Daniel Vetter]

Hi all,

You might have read the short take in the X.org board meeting minutes
already, here's the long version.

The good news: gitlab.fd.o has become very popular with our
communities, and is used extensively. This especially includes all the
CI integration. Modern development process and tooling, yay!

The bad news: The cost in growth has also been tremendous, and it's
breaking our bank account. With reasonable estimates for continued
growth we're expecting hosting expenses totalling 75k USD this year,
and 90k USD next year. With the current sponsors we've set up we can't
sustain that. We estimate that hosting expenses for gitlab.fd.o
without any of the CI features enabled would total 30k USD, which is
within X.org's ability to support through various sponsorships, mostly
through XDC.

Note that X.org does no longer sponsor any CI runners themselves,
we've stopped that. The huge additional expenses are all just in
storing and serving build artifacts and images to outside CI runners
sponsored by various companies. A related topic is that with the
growth in fd.o it's becoming infeasible to maintain it all on
volunteer admin time. X.org is therefore also looking for admin
sponsorship, at least medium term.

Assuming that we want cash flow reserves for one year of gitlab.fd.o
(without CI support) and a trimmed XDC and assuming no sponsor payment
meanwhile, we'd have to cut CI services somewhere between May and June
this year. The board is of course working on acquiring sponsors, but
filling a shortfall of this magnitude is neither easy nor quick work,
and we therefore decided to give an early warning as soon as possible.
Any help in finding sponsors for fd.o is very much appreciated.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/1] drm/amdgpu: Fix per-IB secure flag GFX hang

[Luben Tuikov]

On 2020-02-27 6:56 a.m., Huang Rui wrote:
> On Thu, Feb 27, 2020 at 06:39:03AM +0800, Tuikov, Luben wrote:
>> Since commit "Move to a per-IB secure flag (TMZ)",
>> we've been seeing hangs in GFX. Ray H. pointed out
>> by sending a patch that we need to send FRAME
>> CONTROL stop/start back-to-back, every time we
>> flip the TMZ flag as per each IB we submit. That
>> is, when we transition from TMZ to non-TMZ we have
>> to send a stop with TMZ followed by a start with
>> non-TMZ, and similarly for transitioning from
>> non-TMZ into TMZ.
>>
>> This patch implements this, thus fixing the GFX
>> hang.
>>
>> Signed-off-by: Luben Tuikov 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   | 87 +---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  5 +-
>>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 15 ++--
>>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 ++--
>>  4 files changed, 79 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
>> index 4b2342d11520..16d6df3304d3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
>> @@ -216,40 +216,75 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, 
>> unsigned num_ibs,
>>  amdgpu_ring_emit_cntxcntl(ring, status);
>>  }
>>  
>> -secure = false;
>> +/* Find the first non-preamble IB.
>> + */
>>  for (i = 0; i < num_ibs; ++i) {
>>  ib = [i];
>>  
>>  /* drop preamble IBs if we don't have a context switch */
>> -if ((ib->flags & AMDGPU_IB_FLAG_PREAMBLE) &&
>> -skip_preamble &&
>> -!(status & AMDGPU_PREAMBLE_IB_PRESENT_FIRST) &&
>> -!amdgpu_mcbp &&
>> -!amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble 
>> CE ib must be inserted anyway */
>> -continue;
>> -
>> -/* If this IB is TMZ, add frame TMZ start packet,
>> - * else, turn off TMZ.
>> - */
>> -if (ib->flags & AMDGPU_IB_FLAGS_SECURE && 
>> ring->funcs->emit_tmz) {
>> -if (!secure) {
>> -secure = true;
>> -amdgpu_ring_emit_tmz(ring, true);
>> -}
>> -} else if (secure) {
>> +if (!(ib->flags & AMDGPU_IB_FLAG_PREAMBLE) ||
>> +!skip_preamble ||
>> +(status & AMDGPU_PREAMBLE_IB_PRESENT_FIRST) ||
>> +amdgpu_mcbp ||
>> +amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble CE 
>> ib must be inserted anyway */
>> +break;
>> +}
>> +if (i >= num_ibs)
>> +goto Done;
>> +/* Setup initial TMZiness and send it off.
>> + */
>> +secure = false;
>> +if (job && ring->funcs->emit_frame_cntl) {
>> +if (ib->flags & AMDGPU_IB_FLAGS_SECURE)
>> +secure = true;
>> +else
>>  secure = false;
>> -amdgpu_ring_emit_tmz(ring, false);
>> -}
>> -
>> -amdgpu_ring_emit_ib(ring, job, ib, status);
>> -status &= ~AMDGPU_HAVE_CTX_SWITCH;
>> +amdgpu_ring_emit_frame_cntl(ring, true, secure);
>>  }
>> +amdgpu_ring_emit_ib(ring, job, ib, status);
>> +status &= ~AMDGPU_HAVE_CTX_SWITCH;
>> +i += 1;
>> +/* Send the rest of the IBs.
>> + */
>> +if (job && ring->funcs->emit_frame_cntl) {
>> +for ( ; i < num_ibs; ++i) {
>> +ib = [i];
>> +
>> +/* drop preamble IBs if we don't have a context switch 
>> */
>> +if ((ib->flags & AMDGPU_IB_FLAG_PREAMBLE) &&
>> +skip_preamble &&
>> +!(status & AMDGPU_PREAMBLE_IB_PRESENT_FIRST) &&
>> +!amdgpu_mcbp &&
>> +!amdgpu_sriov_vf(adev)) /* for SRIOV preemption, 
>> Preamble CE ib must be inserted anyway */
>> +continue;
> 
> Snip.
> 
>> +
>> +if (!!secure ^ !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)) {
>> +amdgpu_ring_emit_frame_cntl(ring, false, 
>> secure);
>> +secure = !secure;
>> +amdgpu_ring_emit_frame_cntl(ring, true, secure);
>> +}
> 
> That's pretty good optimization! I spend quit a few time to understand this.

I know. I know you did. It's called experience.

When I saw you v1, it was a cringe. Seriously?

> 
>>  
>> -if (secure) {
>> -secure = false;
>> -amdgpu_ring_emit_tmz(ring, false);
>> +amdgpu_ring_emit_ib(ring, job, ib, status);
>> +status &= ~AMDGPU_HAVE_CTX_SWITCH;
>> +}
>> +amdgpu_ring_emit_frame_cntl(ring, false, secure);
>> +} else {
>> +for ( ; i 

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

[Nirmoy]

On 2/27/20 10:02 PM, Alex Deucher wrote:

On Thu, Feb 27, 2020 at 3:28 PM Nirmoy  wrote:


On 2/27/20 3:35 PM, Alex Deucher wrote:

We shouldn't be changing this at runtime.  We need to set up the queue
priority at init time and then schedule to the appropriate quueue at
runtime.  We set the pipe/queue priority in the mqd (memory queue
descriptor).  When we init the rings we configure the mqds in memory
and then tell the CP to configure the rings.  The CP then fetches the
config from memory (the mqd) and pushes the configuration to the hqd
(hardware queue descriptor).  Currrently we just statically set up the
queues at driver init time, but the hw has the capability to schedule
queues dynamically at runtime.  E.g., we could have a per process mqd
for each queue and then tell the CP to schedule the mqd on the
hardware at runtime.  For now, I think we should just set up some
static pools of rings (e.g., normal and high priority or low, normal,
and high priorities).  Note that you probably want to keep the high
priority queues on a different pipe from the low/normal priority
queues.  Depending on the asic there are 1 or 2 MECs (compute micro
engines) and each MEC supports 4 pipes.  Each pipe can handle up to 8
queues.

After some debugging I realized we have amdgpu_gfx_compute_queue_acquire()

which forces amdgpu to only use queue 0,1 of every pipe form MEC 0 even
if we

have more than 1 MEC.


IIRC, that is to spread the queues across as many pipes as possible.

okay



Does it make sense to have two high priority queue on the same pipe ?

Good question.  Not sure what the best option is for splitting up the
queues.  Maybe one set of queues (low and high) per pipe?


I think a low and high priority queue per pipe should work well AFAIU.


Nirmoy



Alex


Regards,

Nirmoy



Alex


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

Re: [PATCH v3 0/3] Implement SMU message register protection

[Alex Deucher]

On Thu, Feb 27, 2020 at 4:01 PM Matt Coffin  wrote:
>
>
>
> On 2/27/20 1:49 PM, Alex Deucher wrote:
>
> > BTW, I think you had another change to clean up some of the navi10
> > code, care to send that one out too?
> >
> > Alex
>
> That was in there just since I was doing some debugging related to
> https://gitlab.freedesktop.org/drm/amd/issues/1053 and voltage levels
> being different on linux compared to Windows at the same overdrive
> settings. It's not of any use (currently), so I just left it out. It's
> not related to this patchset. I'll toss it in the series I come up with
> that would fix that issue (If I ever get there... I'm pretty stumped at
> this point).
>
> Thanks for checking, though. On it's own, that change would have been
> functionally moot, only required if the GetVoltageByDpmOverdrive SMU
> message becomes useful in the future.
>

Gotcha.

> Not to piggy back on this, but if you have any results, negative or
> positive on the voltage problem, or power limit firmware "problem"
> (https://gitlab.freedesktop.org/drm/amd/issues/1043), I'd love to either
> help reproduce, or work on a fix.

Someone is looking into it, just had other priorities before they
could get to it.  Will update the bug once we get some results.

Thanks!

Alex

>
> Thanks again for the snappy responses, glad I could help out some more!
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

[Alex Deucher]

On Thu, Feb 27, 2020 at 3:28 PM Nirmoy  wrote:
>
>
> On 2/27/20 3:35 PM, Alex Deucher wrote:
> > We shouldn't be changing this at runtime.  We need to set up the queue
> > priority at init time and then schedule to the appropriate quueue at
> > runtime.  We set the pipe/queue priority in the mqd (memory queue
> > descriptor).  When we init the rings we configure the mqds in memory
> > and then tell the CP to configure the rings.  The CP then fetches the
> > config from memory (the mqd) and pushes the configuration to the hqd
> > (hardware queue descriptor).  Currrently we just statically set up the
> > queues at driver init time, but the hw has the capability to schedule
> > queues dynamically at runtime.  E.g., we could have a per process mqd
> > for each queue and then tell the CP to schedule the mqd on the
> > hardware at runtime.  For now, I think we should just set up some
> > static pools of rings (e.g., normal and high priority or low, normal,
> > and high priorities).  Note that you probably want to keep the high
> > priority queues on a different pipe from the low/normal priority
> > queues.  Depending on the asic there are 1 or 2 MECs (compute micro
> > engines) and each MEC supports 4 pipes.  Each pipe can handle up to 8
> > queues.
>
> After some debugging I realized we have amdgpu_gfx_compute_queue_acquire()
>
> which forces amdgpu to only use queue 0,1 of every pipe form MEC 0 even
> if we
>
> have more than 1 MEC.
>

IIRC, that is to spread the queues across as many pipes as possible.

>
> Does it make sense to have two high priority queue on the same pipe ?

Good question.  Not sure what the best option is for splitting up the
queues.  Maybe one set of queues (low and high) per pipe?

Alex

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

Re: [PATCH v3 0/3] Implement SMU message register protection

[Matt Coffin]

On 2/27/20 1:49 PM, Alex Deucher wrote:

> BTW, I think you had another change to clean up some of the navi10
> code, care to send that one out too?
> 
> Alex

That was in there just since I was doing some debugging related to
https://gitlab.freedesktop.org/drm/amd/issues/1053 and voltage levels
being different on linux compared to Windows at the same overdrive
settings. It's not of any use (currently), so I just left it out. It's
not related to this patchset. I'll toss it in the series I come up with
that would fix that issue (If I ever get there... I'm pretty stumped at
this point).

Thanks for checking, though. On it's own, that change would have been
functionally moot, only required if the GetVoltageByDpmOverdrive SMU
message becomes useful in the future.

Not to piggy back on this, but if you have any results, negative or
positive on the voltage problem, or power limit firmware "problem"
(https://gitlab.freedesktop.org/drm/amd/issues/1043), I'd love to either
help reproduce, or work on a fix.

Thanks again for the snappy responses, glad I could help out some more!
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 0/3] Implement SMU message register protection

[Alex Deucher]

On Wed, Feb 26, 2020 at 6:16 PM Matt Coffin  wrote:
>
> Sorry for the extra email, but the mutex_init got lost when I was rebasing. 
> Oops.
>
> This patchset adds a message lock to lock access to the SMU message
> communication registers to prevent concurrent access.
>
> v2: Separate navi10 change out into a separate patch, and remove mutex
> definition from first patch
>
> v3: Re-add mutex_init to amdgpu_smu.c. It got lost in the rebase
>
> For Alex's concerns, I omitted one of them, though I can re-submit if
> it's still desired. since smu_send_smc_msg was previously around, and is
> used in lots of places, I left it alone rather than replace every
> occurance as it still makes sense to be able to safely send messages
> without arguments, without knowing that the default argument should be
> zero.

I've tested and applied the patches.  I'll get the team to do some
more testing across more asics as well.  Thanks!

BTW, I think you had another change to clean up some of the navi10
code, care to send that one out too?

Alex

>
> Matt Coffin (3):
>   drm/amdgpu/powerplay: Refactor SMU message handling for safety
>   drm/amdgpu/powerplay: Remove deprecated smc_read_arg
>   drm/amdgpu/smu: Add message sending lock
>
>  drivers/gpu/drm/amd/powerplay/amdgpu_smu.c|  47 ++-
>  drivers/gpu/drm/amd/powerplay/arcturus_ppt.c  |  30 +++--
>  .../gpu/drm/amd/powerplay/inc/amdgpu_smu.h|   4 +-
>  drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h |   5 +-
>  drivers/gpu/drm/amd/powerplay/inc/smu_v12_0.h |   5 +-
>  drivers/gpu/drm/amd/powerplay/navi10_ppt.c|  35 ++---
>  drivers/gpu/drm/amd/powerplay/renoir_ppt.c|  26 ++--
>  drivers/gpu/drm/amd/powerplay/smu_internal.h  |  11 +-
>  drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 120 +-
>  drivers/gpu/drm/amd/powerplay/smu_v12_0.c |  87 +++--
>  drivers/gpu/drm/amd/powerplay/vega20_ppt.c|  69 ++
>  11 files changed, 220 insertions(+), 219 deletions(-)
>
> --
> 2.25.0
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/2] drm/amdgpu: remove unused variable

[Zhao, Yong]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Yong Zhao 

From: amd-gfx  on behalf of Alex Deucher 

Sent: Thursday, February 27, 2020 3:14 PM
To: amd-gfx@lists.freedesktop.org 
Cc: Deucher, Alexander 
Subject: [PATCH 1/2] drm/amdgpu: remove unused variable

Fixes a warning.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index bec4337156a7..b3e32969eb7f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1131,7 +1131,6 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)
 {
 struct drm_device *dev = pci_get_drvdata(pdev);
-   struct amdgpu_device *adev = dev->dev_private;

 #ifdef MODULE
 if (THIS_MODULE->state != MODULE_STATE_GOING)
--
2.24.1

___
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-gfxdata=02%7C01%7Cyong.zhao%40amd.com%7Ca4b7a490c31647472ca608d7bbc1bc24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637184313087705310sdata=LNUqZiHj4Ey7KHjtp1o2c%2BpYO87JeL61VAYfNwNiE0Q%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu/gfx: fix indentation in new rlc spm code

[Nirmoy]

series Reviewed-by:Nirmoy Das 

On 2/27/20 9:14 PM, Alex Deucher wrote:

fixes warnings with -Wmisleading-indentation.

Signed-off-by: Alex Deucher 
---
  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 +++---
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  | 6 +++---
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 6 +++---
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 6 +++---
  4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index cb3421e25adc..0dc3ed694fe8 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -1016,9 +1016,9 @@ static int gfx_v10_0_rlc_init(struct amdgpu_device *adev)
return r;
}
  
-/* init spm vmid with 0xf */

-if (adev->gfx.rlc.funcs->update_spm_vmid)
-adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+   /* init spm vmid with 0xf */
+   if (adev->gfx.rlc.funcs->update_spm_vmid)
+   adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
  
  	return 0;

  }
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 397c62c58436..733d398c61cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -3346,9 +3346,9 @@ static int gfx_v7_0_rlc_init(struct amdgpu_device *adev)
return r;
}
  
-/* init spm vmid with 0xf */

-if (adev->gfx.rlc.funcs->update_spm_vmid)
-adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+   /* init spm vmid with 0xf */
+   if (adev->gfx.rlc.funcs->update_spm_vmid)
+   adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
  
  	return 0;

  }
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 294abff9efb7..393a1324daa9 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -1318,9 +1318,9 @@ static int gfx_v8_0_rlc_init(struct amdgpu_device *adev)
return r;
}
  
-/* init spm vmid with 0xf */

-if (adev->gfx.rlc.funcs->update_spm_vmid)
-adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+   /* init spm vmid with 0xf */
+   if (adev->gfx.rlc.funcs->update_spm_vmid)
+   adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
  
  	return 0;

  }
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 1d5fd5f17a30..9962ef80da92 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1847,9 +1847,9 @@ static int gfx_v9_0_rlc_init(struct amdgpu_device *adev)
break;
}
  
-/* init spm vmid with 0xf */

-if (adev->gfx.rlc.funcs->update_spm_vmid)
-adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+   /* init spm vmid with 0xf */
+   if (adev->gfx.rlc.funcs->update_spm_vmid)
+   adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
  
  	return 0;

  }

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

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

[Nirmoy]

On 2/27/20 3:35 PM, Alex Deucher wrote:

We shouldn't be changing this at runtime.  We need to set up the queue
priority at init time and then schedule to the appropriate quueue at
runtime.  We set the pipe/queue priority in the mqd (memory queue
descriptor).  When we init the rings we configure the mqds in memory
and then tell the CP to configure the rings.  The CP then fetches the
config from memory (the mqd) and pushes the configuration to the hqd
(hardware queue descriptor).  Currrently we just statically set up the
queues at driver init time, but the hw has the capability to schedule
queues dynamically at runtime.  E.g., we could have a per process mqd
for each queue and then tell the CP to schedule the mqd on the
hardware at runtime.  For now, I think we should just set up some
static pools of rings (e.g., normal and high priority or low, normal,
and high priorities).  Note that you probably want to keep the high
priority queues on a different pipe from the low/normal priority
queues.  Depending on the asic there are 1 or 2 MECs (compute micro
engines) and each MEC supports 4 pipes.  Each pipe can handle up to 8
queues.


After some debugging I realized we have amdgpu_gfx_compute_queue_acquire()

which forces amdgpu to only use queue 0,1 of every pipe form MEC 0 even 
if we


have more than 1 MEC.


Does it make sense to have two high priority queue on the same pipe ?

Regards,

Nirmoy



Alex




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

[PATCH 2/2] drm/amdgpu/gfx: fix indentation in new rlc spm code

[Alex Deucher]

fixes warnings with -Wmisleading-indentation.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 +++---
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  | 6 +++---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 6 +++---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index cb3421e25adc..0dc3ed694fe8 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -1016,9 +1016,9 @@ static int gfx_v10_0_rlc_init(struct amdgpu_device *adev)
return r;
}
 
-/* init spm vmid with 0xf */
-if (adev->gfx.rlc.funcs->update_spm_vmid)
-adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+   /* init spm vmid with 0xf */
+   if (adev->gfx.rlc.funcs->update_spm_vmid)
+   adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
 
return 0;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 397c62c58436..733d398c61cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -3346,9 +3346,9 @@ static int gfx_v7_0_rlc_init(struct amdgpu_device *adev)
return r;
}
 
-/* init spm vmid with 0xf */
-if (adev->gfx.rlc.funcs->update_spm_vmid)
-adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+   /* init spm vmid with 0xf */
+   if (adev->gfx.rlc.funcs->update_spm_vmid)
+   adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
 
return 0;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 294abff9efb7..393a1324daa9 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -1318,9 +1318,9 @@ static int gfx_v8_0_rlc_init(struct amdgpu_device *adev)
return r;
}
 
-/* init spm vmid with 0xf */
-if (adev->gfx.rlc.funcs->update_spm_vmid)
-adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+   /* init spm vmid with 0xf */
+   if (adev->gfx.rlc.funcs->update_spm_vmid)
+   adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
 
return 0;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 1d5fd5f17a30..9962ef80da92 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1847,9 +1847,9 @@ static int gfx_v9_0_rlc_init(struct amdgpu_device *adev)
break;
}
 
-/* init spm vmid with 0xf */
-if (adev->gfx.rlc.funcs->update_spm_vmid)
-adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+   /* init spm vmid with 0xf */
+   if (adev->gfx.rlc.funcs->update_spm_vmid)
+   adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
 
return 0;
 }
-- 
2.24.1

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

[PATCH 1/2] drm/amdgpu: remove unused variable

[Alex Deucher]

Fixes a warning.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index bec4337156a7..b3e32969eb7f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1131,7 +1131,6 @@ static void
 amdgpu_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
-   struct amdgpu_device *adev = dev->dev_private;
 
 #ifdef MODULE
if (THIS_MODULE->state != MODULE_STATE_GOING)
-- 
2.24.1

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

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

[Mario Kleiner]

Hi Harry

Ok, back from various other emergencies and deadlines, sorry for the
late reply. I also fixed my e-mail address - it was mistyped, causing
all these delivery failures :/

On Thu, Jan 9, 2020 at 10:26 PM Harry Wentland  wrote:
>
> On 2020-01-09 4:13 p.m., Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 7:44 PM Harry Wentland  > > wrote:
> >
> > On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> > > If the current eDP link settings, as read from hw, provide a higher
> > > bandwidth than the verified_link_cap ones (= reported_link_cap), then
> > > override verified_link_cap with current settings.
> > >
> > > These initial current eDP link settings have been set up by
> > > firmware during boot, so they should work on the eDP panel.
> > > Therefore use them if the firmware thinks they are good and
> > > they provide higher link bandwidth, e.g., to enable higher
> > > resolutions / color depths.
> > >
... snip ...
> >
> >
> > Tried that already (see other mail), replacing the whole if statement
> > with a if (true) to force reading DP_SUPPORTED_LINK_RATES. The whole
> > table reads back as all-zero, and versions are DP 1.1, eDP 1.3, not 1.4+
> > as what seems to be required. The use the classic link bw stuff, but
> > with a non-standard link bandwidth multiplier of 0xc, and a reported
> > DP_MAX_LINK_RATE of 0xa, contradicting the 0xc setting that the firmware
> > sets at bootup.
> >
> > Seems to be a very Apple thing...
>
> Indeed. I think it was a funky panel that was "ahead of its time" and
> ahead of the spec.
>
> I would prefer a DPCD quirk for this panel that updates the reported DP
> caps, rather than picking the "current" ones from the FW lightup.
>
> Harry
>

How would i do this? I see various options:

I could rewrite my current patch, move it down inside
dc_link_detect_helper() until after the edid was read and we have
vendor/model id available, then say if(everything that's there now &&
(vendor=Apple) && (model=Troublesomepanel)) { ... }

Or i could add quirk code to detect_edp_sink_caps() after
retrieve_link_cap() [or inside retrieve_link_cap] to override the
reported_link_cap. But at that point we don't have edid yet and
therefore no vendor/model id. Is there something inside the dpcd one
can use to uniquely identify this display model?

struct dp_device_vendor_id sink_id; queried inside retrieve_link_cap()
sounds like it could be a unique id? I don't know about that.

My intention was to actually do nothing on the AMD side here, as my
photometer measurements suggest that the panel gives better quality
results for >= 10 bpc output if it is operated at 8 bit and then the
gpu's spatial dithering convincingly fakes the extra bits. Quality
seems worse if one actually switches the panel into 10 bpc, as it
doesn't seem to be a real 10 bit panel, just a 8 bit panel that
accepts 10 bit and then badly dithers it to 10 bit.

The situation has changed for Linux 5.6-rc, because of this recent
commit from Roman Li, which is already in 5.6-rc:
4a8ca46bae8affba063aabac85a0b1401ba810a3 "drm/amd/display: Default max
bpc to 16 for eDP"

While that commit supposedly fixes some darkness on some other eDP
panel, it now breaks my eDP panel. It leaves edid reported bpc
unclamped, so the driver uses 10 bpc as basis for required bandwidth
calculations and then the required bandwidth for all modes exceeds the
link bandwidth. I end with the eDP panel having no valid modes at all
==> Panel goes black, game over.

We either need to revert that commit for drm-fixes, or quirk it for
the specific panels that are troublesome, or need to get some solution
into 5.6-rc, otherwise there will be a lot of regressions for at least
Apple MBP users.

thanks,
-mario

> > -mario
> >
> >
> >
> > Thanks,
> > Harry
> >
> > > This fixes a problem found on the MacBookPro 2017 Retina panel:
> > >
> > > The panel reports 10 bpc color depth in its EDID, and the
> > > firmware chooses link settings at boot which support enough
> > > bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2),
> > > but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps
> > > as possible, so verified_link_cap is only good for 2.7 Gbps
> > > and 8 bpc, not providing the full color depth of the panel.
> > >
> > > Signed-off-by: Mario Kleiner  > >
> > > Cc: Alex Deucher  > >
> > > ---
> > >  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21
> > +++
> > >  1 file changed, 21 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > > index 5ea4a1675259..f3acdb8fead5 100644
> > > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > > @@ -819,6 +819,27 @@ static 

RE: [PATCH 2/2] drm/amd/display: dc_link: code clean up on detect_dp function

[Liu, Zhan]

> -Original Message-
> From: amd-gfx  On Behalf Of Liu,
> Zhan
> Sent: 2020/February/27, Thursday 1:40 PM
> To: Melissa Wen ; Wentland, Harry
> ; Li, Sun peng (Leo) ;
> Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
> ; Rodrigo Siqueira 
> Cc: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: RE: [PATCH 2/2] drm/amd/display: dc_link: code clean up on
> detect_dp function
> 
> 
> > -Original Message-
> > From: amd-gfx  On Behalf Of
> > Melissa Wen
> > Sent: 2020/February/26, Wednesday 5:08 PM
> > To: Wentland, Harry ; Li, Sun peng (Leo)
> > ; Deucher, Alexander
> ;
> > Koenig, Christian ; Zhou, David(ChunMing)
> > ; David Airlie ; Daniel Vetter
> > ; Rodrigo Siqueira 
> > Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org;
> > linux- ker...@vger.kernel.org
> > Subject: [PATCH 2/2] drm/amd/display: dc_link: code clean up on
> > detect_dp function
> >
> > Removes codestyle issues on detect_dp function as suggested by
> > checkpatch.pl.
> >
> > CHECK: Lines should not end with a '('
> > WARNING: Missing a blank line after declarations
> > WARNING: line over 80 characters
> > CHECK: Alignment should match open parenthesis
> >
> > Signed-off-by: Melissa Wen 
> 
> Thank you Melissa for your contribution! Will apply it.
> 
> This patch is:
> Reviewed-by: Zhan Liu 

Sorry I didn't see Rodrigo already replied your email. Please send us a V2, 
then we will review your V2 patch.

And again, thank you so much for your contribution!

Zhan

> 
> > ---
> >  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 35
> > +--
> >  1 file changed, 16 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > index 0f28b5694144..adb717f02c9c 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > @@ -585,14 +585,14 @@ static void
> > read_current_link_settings_on_detect(struct dc_link *link)
> > LINK_SPREAD_05_DOWNSPREAD_30KHZ :
> > LINK_SPREAD_DISABLED;  }
> >
> > -static bool detect_dp(
> > -   struct dc_link *link,
> > -   struct display_sink_capability *sink_caps,
> > -   bool *converter_disable_audio,
> > -   struct audio_support *audio_support,
> > -   enum dc_detect_reason reason)
> > +static bool detect_dp(struct dc_link *link,
> > + struct display_sink_capability *sink_caps,
> > + bool *converter_disable_audio,
> > + struct audio_support *audio_support,
> > + enum dc_detect_reason reason)
> >  {
> > bool boot = false;
> > +
> > sink_caps->signal = link_detect_sink(link, reason);
> > sink_caps->transaction_type =
> > get_ddc_transaction_type(sink_caps->signal);
> > @@ -606,9 +606,8 @@ static bool detect_dp(
> > sink_caps->signal =
> > SIGNAL_TYPE_DISPLAY_PORT_MST;
> > link->type = dc_connection_mst_branch;
> >
> > -   dal_ddc_service_set_transaction_type(
> > -   link->ddc,
> > -   sink_caps-
> > >transaction_type);
> > +   dal_ddc_service_set_transaction_type(link->ddc,
> > +sink_caps-
> > >transaction_type);
> >
> > /*
> >  * This call will initiate MST topology discovery.
> > Which @@ -637,13 +636,10 @@ static bool detect_dp(
> > if (reason == DETECT_REASON_BOOT)
> > boot = true;
> >
> > -   dm_helpers_dp_update_branch_info(
> > -   link->ctx,
> > -   link);
> > +   dm_helpers_dp_update_branch_info(link->ctx, link);
> >
> > -   if (!dm_helpers_dp_mst_start_top_mgr(
> > -   link->ctx,
> > -   link, boot)) {
> > +   if (!dm_helpers_dp_mst_start_top_mgr(link->ctx,
> > +link, boot)) {
> > /* MST not supported */
> > link->type = dc_connection_single;
> > sink_caps->signal =
> > SIGNAL_TYPE_DISPLAY_PORT; @@ -651,7 +647,7 @@ static bool
> detect_dp(
> > }
> >
> > if (link->type != dc_connection_mst_branch &&
> > -   is_dp_active_dongle(link)) {
> > +   is_dp_active_dongle(link)) {
> > /* DP active dongles */
> > link->type = dc_connection_active_dongle;
> > if (!link->dpcd_caps.sink_count.bits.SINK_COUNT)
> > { @@ -662,14 +658,15 @@ static bool detect_dp(
> > return true;
> > 

Re: [PATCH] drm/amdgpu: stop allocating PDs/PTs with the eviction lock held

[Felix Kuehling]

On 2020-02-27 9:28, Christian König wrote:

Hi Felix,

so coming back to this after two weeks of distraction.

Am 14.02.20 um 22:12 schrieb Felix Kuehling:
Now you allow eviction of page tables while you allocate page tables. 
Isn't the whole point of the eviction lock to prevent page table 
evictions while manipulating page tables?


Or does this only apply to PTE invalidations which never allocated 
memory? Is that the only case that doesn't reserve page tables?


Yes, exactly. We essentially have to distinct two cases here:

1. We are validating PTEs and so eventually need to allocate page tables.
    For this the root PD is reserved and we actually know that the VM 
can't be evicted.
    But we still need to hold the lock while pushing the actual 
updates the hardware to make sure we don't mess up the data structures 
with concurrent invalidations.


2. We are invalidating PTEs.
    Here we might or might not have the root PD reserved and so need 
to make sure that nobody is evicting page tables while we are 
invalidating.


Quite a complicated dance, but of hand I also don't see much other 
choice.


Sounds good. Maybe we should have an assert that the root PD is reserved 
in amdgpu_vm_alloc_pts. With that modification the patch is


Reviewed-by: Felix Kuehling 




Regards,
Christian.



Regards,
  Felix

On 2020-02-12 10:14 a.m., Christian König wrote:

We need to make sure to not allocate PDs/PTs while holding
the eviction lock or otherwise we will run into lock inversion
in the MM as soon as we enable the MMU notifier.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 31 
+-

  1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index 77c400675b79..e7ab0c1e2793 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -897,27 +897,42 @@ static int amdgpu_vm_alloc_pts(struct 
amdgpu_device *adev,

  struct amdgpu_vm_pt *entry = cursor->entry;
  struct amdgpu_bo_param bp;
  struct amdgpu_bo *pt;
+    bool need_entries;
  int r;
  -    if (cursor->level < AMDGPU_VM_PTB && !entry->entries) {
+    need_entries = cursor->level < AMDGPU_VM_PTB && !entry->entries;
+    if (!need_entries && entry->base.bo)
+    return 0;
+
+    /* We need to make sure that we don't allocate PDs/PTs while 
holding the

+ * eviction lock or we run into lock recursion in the MM.
+ */
+    amdgpu_vm_eviction_unlock(vm);
+
+    if (need_entries) {
  unsigned num_entries;
    num_entries = amdgpu_vm_num_entries(adev, cursor->level);
  entry->entries = kvmalloc_array(num_entries,
  sizeof(*entry->entries),
  GFP_KERNEL | __GFP_ZERO);
-    if (!entry->entries)
-    return -ENOMEM;
+    if (!entry->entries) {
+    r = -ENOMEM;
+    goto error_lock;
+    }
  }
  -    if (entry->base.bo)
-    return 0;
+    if (entry->base.bo) {
+    r = 0;
+    goto error_lock;
+    }
    amdgpu_vm_bo_param(adev, vm, cursor->level, direct, );
    r = amdgpu_bo_create(adev, , );
+    amdgpu_vm_eviction_lock(vm);
  if (r)
-    return r;
+    goto error_free_pt;
    /* Keep a reference to the root directory to avoid
   * freeing them up in the wrong order.
@@ -936,6 +951,10 @@ static int amdgpu_vm_alloc_pts(struct 
amdgpu_device *adev,

  amdgpu_bo_unref();
  entry->base.bo = NULL;
  return r;
+
+error_lock:
+    amdgpu_vm_eviction_lock(vm);
+    return r;
  }
    /**



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

RE: [PATCH 2/2] drm/amd/display: dc_link: code clean up on detect_dp function

[Liu, Zhan]

> -Original Message-
> From: amd-gfx  On Behalf Of
> Melissa Wen
> Sent: 2020/February/26, Wednesday 5:08 PM
> To: Wentland, Harry ; Li, Sun peng (Leo)
> ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
> ; Rodrigo Siqueira 
> Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH 2/2] drm/amd/display: dc_link: code clean up on detect_dp
> function
> 
> Removes codestyle issues on detect_dp function as suggested by
> checkpatch.pl.
> 
> CHECK: Lines should not end with a '('
> WARNING: Missing a blank line after declarations
> WARNING: line over 80 characters
> CHECK: Alignment should match open parenthesis
> 
> Signed-off-by: Melissa Wen 

Thank you Melissa for your contribution! Will apply it.

This patch is:
Reviewed-by: Zhan Liu 

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 35 +--
>  1 file changed, 16 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index 0f28b5694144..adb717f02c9c 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -585,14 +585,14 @@ static void
> read_current_link_settings_on_detect(struct dc_link *link)
>   LINK_SPREAD_05_DOWNSPREAD_30KHZ :
> LINK_SPREAD_DISABLED;  }
> 
> -static bool detect_dp(
> - struct dc_link *link,
> - struct display_sink_capability *sink_caps,
> - bool *converter_disable_audio,
> - struct audio_support *audio_support,
> - enum dc_detect_reason reason)
> +static bool detect_dp(struct dc_link *link,
> +   struct display_sink_capability *sink_caps,
> +   bool *converter_disable_audio,
> +   struct audio_support *audio_support,
> +   enum dc_detect_reason reason)
>  {
>   bool boot = false;
> +
>   sink_caps->signal = link_detect_sink(link, reason);
>   sink_caps->transaction_type =
>   get_ddc_transaction_type(sink_caps->signal);
> @@ -606,9 +606,8 @@ static bool detect_dp(
>   sink_caps->signal =
> SIGNAL_TYPE_DISPLAY_PORT_MST;
>   link->type = dc_connection_mst_branch;
> 
> - dal_ddc_service_set_transaction_type(
> - link->ddc,
> - sink_caps-
> >transaction_type);
> + dal_ddc_service_set_transaction_type(link->ddc,
> +  sink_caps-
> >transaction_type);
> 
>   /*
>* This call will initiate MST topology discovery.
> Which @@ -637,13 +636,10 @@ static bool detect_dp(
>   if (reason == DETECT_REASON_BOOT)
>   boot = true;
> 
> - dm_helpers_dp_update_branch_info(
> - link->ctx,
> - link);
> + dm_helpers_dp_update_branch_info(link->ctx, link);
> 
> - if (!dm_helpers_dp_mst_start_top_mgr(
> - link->ctx,
> - link, boot)) {
> + if (!dm_helpers_dp_mst_start_top_mgr(link->ctx,
> +  link, boot)) {
>   /* MST not supported */
>   link->type = dc_connection_single;
>   sink_caps->signal =
> SIGNAL_TYPE_DISPLAY_PORT; @@ -651,7 +647,7 @@ static bool detect_dp(
>   }
> 
>   if (link->type != dc_connection_mst_branch &&
> - is_dp_active_dongle(link)) {
> + is_dp_active_dongle(link)) {
>   /* DP active dongles */
>   link->type = dc_connection_active_dongle;
>   if (!link->dpcd_caps.sink_count.bits.SINK_COUNT)
> { @@ -662,14 +658,15 @@ static bool detect_dp(
>   return true;
>   }
> 
> - if (link->dpcd_caps.dongle_type !=
> DISPLAY_DONGLE_DP_HDMI_CONVERTER)
> + if (link->dpcd_caps.dongle_type !=
> + DISPLAY_DONGLE_DP_HDMI_CONVERTER)
>   *converter_disable_audio = true;
>   }
>   } else {
>   /* DP passive dongles */
>   sink_caps->signal = dp_passive_dongle_detection(link->ddc,
> - sink_caps,
> - audio_support);
> + sink_caps,
> +
>   audio_support);
>   }
> 
>   return true;
> --
> 2.25.0
> 
> ___
> amd-gfx mailing list
> 

Re: [PATCH 0/2] drm/amd/display: dc_link: cleaning up some code style issues

[Melissa Wen]

Hi Rodrigo,

On 02/27, Rodrigo Siqueira wrote:
> Hi Melissa,
> 
> First of all, thank you very much for this patchset; in general,
> everything looks good to me.
> 
> I noticed that your patchset does not apply because you made your
> changes based on `drm-misc-next`; when you send patches to amdgpu, use
> the following repository:
> 
>  git://people.freedesktop.org/~agd5f/linux 
> 
> Could you prepare a V2?
Yes.

Thanks for reviewing my patches.
Soon, I will send a V2 with the changes suggested by you. 
> 
> Thanks!
> 
> On 02/26, Melissa Wen wrote:
> > This patchset solves some coding style issues on dc_link for readability
> > and cleaning up warnings. Change suggested by checkpatch.pl. 
> > 
> > Melissa Wen (2):
> >   drm/amd/display: dc_link: code clean up on enable_link_dp function
> >   drm/amd/display: dc_link: code clean up on detect_dp function
> > 
> >  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 67 +--
> >  1 file changed, 32 insertions(+), 35 deletions(-)
> > 
> > -- 
> > 2.25.0
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7C7a3e02e3f43447ed4fab08d7bb080d9b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183515885211986sdata=bnipkrUtKdO1oOKxdt1th4iIG1%2BBgl2wMPVrdmn3P1U%3Dreserved=0
> 
> -- 
> Rodrigo Siqueira
> https://siqueira.tech

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

Re: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

[Alex Deucher]

On Thu, Feb 27, 2020 at 10:54 AM Hersen Wu  wrote:
>
>  This interface is for dGPU Navi1x. Linux dc-pplib interface depends
>  on window driver dc implementation.
>
>  For Navi1x, clock settings of dcn watermarks are fixed. the settings
>  should be passed to smu during boot up and resume from s3.
>  boot up: dc calculate dcn watermark clock settings within dc_create,
>  dcn20_resource_construct, then call pplib functions below to pass
>  the settings to smu:
>  smu_set_watermarks_for_clock_ranges
>  smu_set_watermarks_table
>  navi10_set_watermarks_table
>  smu_write_watermarks_table
>
>  For Renoir, clock settings of dcn watermark are also fixed values.
>  dc has implemented different flow for window driver:
>  dc_hardware_init / dc_set_power_state
>  dcn10_init_hw
>  notify_wm_ranges
>  set_wm_ranges
>
>  For Linux
>  smu_set_watermarks_for_clock_ranges
>  renoir_set_watermarks_table
>  smu_write_watermarks_table
>
>  dc_hardware_init -> amdgpu_dm_init
>  dc_set_power_state --> dm_resume
>
>  therefore, linux dc-pplib interface of navi10/12/14 is different
>  from that of Renoir.
>
> Signed-off-by: Hersen Wu 

Acked-by: Alex Deucher 

> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 64 +++
>  1 file changed, 64 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 931cbd7b372e..c58c0e95735e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1435,6 +1435,68 @@ static void s3_handle_mst(struct drm_device *dev, bool 
> suspend)
> drm_kms_helper_hotplug_event(dev);
>  }
>
> +static int amdgpu_dm_smu_write_watermarks_table(struct amdgpu_device *adev)
> +{
> +   struct smu_context *smu = >smu;
> +   int ret = 0;
> +
> +   if (!is_support_sw_smu(adev))
> +   return 0;
> +
> +   /* This interface is for dGPU Navi1x.Linux dc-pplib interface depends
> +* on window driver dc implementation.
> +* For Navi1x, clock settings of dcn watermarks are fixed. the 
> settings
> +* should be passed to smu during boot up and resume from s3.
> +* boot up: dc calculate dcn watermark clock settings within 
> dc_create,
> +* dcn20_resource_construct
> +* then call pplib functions below to pass the settings to smu:
> +* smu_set_watermarks_for_clock_ranges
> +* smu_set_watermarks_table
> +* navi10_set_watermarks_table
> +* smu_write_watermarks_table
> +*
> +* For Renoir, clock settings of dcn watermark are also fixed values.
> +* dc has implemented different flow for window driver:
> +* dc_hardware_init / dc_set_power_state
> +* dcn10_init_hw
> +* notify_wm_ranges
> +* set_wm_ranges
> +* -- Linux
> +* smu_set_watermarks_for_clock_ranges
> +* renoir_set_watermarks_table
> +* smu_write_watermarks_table
> +*
> +* For Linux,
> +* dc_hardware_init -> amdgpu_dm_init
> +* dc_set_power_state --> dm_resume
> +*
> +* therefore, this function apply to navi10/12/14 but not Renoir
> +* *
> +*/
> +   switch(adev->asic_type) {
> +   case CHIP_NAVI10:
> +   case CHIP_NAVI14:
> +   case CHIP_NAVI12:
> +   break;
> +   default:
> +   return 0;
> +   }
> +
> +   /* pass data to smu controller */
> +   if ((smu->watermarks_bitmap & WATERMARKS_EXIST) &&
> +   !(smu->watermarks_bitmap & WATERMARKS_LOADED)) {
> +   ret = smu_write_watermarks_table(smu);
> +
> +   if (ret) {
> +   DRM_ERROR("Failed to update WMTABLE!\n");
> +   return ret;
> +   }
> +   smu->watermarks_bitmap |= WATERMARKS_LOADED;
> +   }
> +
> +   return 0;
> +}
> +
>  /**
>   * dm_hw_init() - Initialize DC device
>   * @handle: The base driver device containing the amdgpu_dm device.
> @@ -1713,6 +1775,8 @@ static int dm_resume(void *handle)
>
> amdgpu_dm_irq_resume_late(adev);
>
> +   amdgpu_dm_smu_write_watermarks_table(adev);
> +
> return 0;
>  }
>
> --
> 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

[PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

[Hersen Wu]

 This interface is for dGPU Navi1x. Linux dc-pplib interface depends
 on window driver dc implementation.

 For Navi1x, clock settings of dcn watermarks are fixed. the settings
 should be passed to smu during boot up and resume from s3.
 boot up: dc calculate dcn watermark clock settings within dc_create,
 dcn20_resource_construct, then call pplib functions below to pass
 the settings to smu:
 smu_set_watermarks_for_clock_ranges
 smu_set_watermarks_table
 navi10_set_watermarks_table
 smu_write_watermarks_table

 For Renoir, clock settings of dcn watermark are also fixed values.
 dc has implemented different flow for window driver:
 dc_hardware_init / dc_set_power_state
 dcn10_init_hw
 notify_wm_ranges
 set_wm_ranges

 For Linux
 smu_set_watermarks_for_clock_ranges
 renoir_set_watermarks_table
 smu_write_watermarks_table

 dc_hardware_init -> amdgpu_dm_init
 dc_set_power_state --> dm_resume

 therefore, linux dc-pplib interface of navi10/12/14 is different
 from that of Renoir.

Signed-off-by: Hersen Wu 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 64 +++
 1 file changed, 64 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 931cbd7b372e..c58c0e95735e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1435,6 +1435,68 @@ static void s3_handle_mst(struct drm_device *dev, bool 
suspend)
drm_kms_helper_hotplug_event(dev);
 }
 
+static int amdgpu_dm_smu_write_watermarks_table(struct amdgpu_device *adev)
+{
+   struct smu_context *smu = >smu;
+   int ret = 0;
+
+   if (!is_support_sw_smu(adev))
+   return 0;
+
+   /* This interface is for dGPU Navi1x.Linux dc-pplib interface depends
+* on window driver dc implementation.
+* For Navi1x, clock settings of dcn watermarks are fixed. the settings
+* should be passed to smu during boot up and resume from s3.
+* boot up: dc calculate dcn watermark clock settings within dc_create,
+* dcn20_resource_construct
+* then call pplib functions below to pass the settings to smu:
+* smu_set_watermarks_for_clock_ranges
+* smu_set_watermarks_table
+* navi10_set_watermarks_table
+* smu_write_watermarks_table
+*
+* For Renoir, clock settings of dcn watermark are also fixed values.
+* dc has implemented different flow for window driver:
+* dc_hardware_init / dc_set_power_state
+* dcn10_init_hw
+* notify_wm_ranges
+* set_wm_ranges
+* -- Linux
+* smu_set_watermarks_for_clock_ranges
+* renoir_set_watermarks_table
+* smu_write_watermarks_table
+*
+* For Linux,
+* dc_hardware_init -> amdgpu_dm_init
+* dc_set_power_state --> dm_resume
+*
+* therefore, this function apply to navi10/12/14 but not Renoir
+* *
+*/
+   switch(adev->asic_type) {
+   case CHIP_NAVI10:
+   case CHIP_NAVI14:
+   case CHIP_NAVI12:
+   break;
+   default:
+   return 0;
+   }
+
+   /* pass data to smu controller */
+   if ((smu->watermarks_bitmap & WATERMARKS_EXIST) &&
+   !(smu->watermarks_bitmap & WATERMARKS_LOADED)) {
+   ret = smu_write_watermarks_table(smu);
+
+   if (ret) {
+   DRM_ERROR("Failed to update WMTABLE!\n");
+   return ret;
+   }
+   smu->watermarks_bitmap |= WATERMARKS_LOADED;
+   }
+
+   return 0;
+}
+
 /**
  * dm_hw_init() - Initialize DC device
  * @handle: The base driver device containing the amdgpu_dm device.
@@ -1713,6 +1775,8 @@ static int dm_resume(void *handle)
 
amdgpu_dm_irq_resume_late(adev);
 
+   amdgpu_dm_smu_write_watermarks_table(adev);
+
return 0;
 }
 
-- 
2.17.1

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

Re: [PATCH] drm/amdgpu: stop allocating PDs/PTs with the eviction lock held

[Christian König]

Hi Felix,

so coming back to this after two weeks of distraction.

Am 14.02.20 um 22:12 schrieb Felix Kuehling:
Now you allow eviction of page tables while you allocate page tables. 
Isn't the whole point of the eviction lock to prevent page table 
evictions while manipulating page tables?


Or does this only apply to PTE invalidations which never allocated 
memory? Is that the only case that doesn't reserve page tables?


Yes, exactly. We essentially have to distinct two cases here:

1. We are validating PTEs and so eventually need to allocate page tables.
    For this the root PD is reserved and we actually know that the VM 
can't be evicted.
    But we still need to hold the lock while pushing the actual updates 
the hardware to make sure we don't mess up the data structures with 
concurrent invalidations.


2. We are invalidating PTEs.
    Here we might or might not have the root PD reserved and so need to 
make sure that nobody is evicting page tables while we are invalidating.


Quite a complicated dance, but of hand I also don't see much other choice.

Regards,
Christian.



Regards,
  Felix

On 2020-02-12 10:14 a.m., Christian König wrote:

We need to make sure to not allocate PDs/PTs while holding
the eviction lock or otherwise we will run into lock inversion
in the MM as soon as we enable the MMU notifier.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 31 +-
  1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index 77c400675b79..e7ab0c1e2793 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -897,27 +897,42 @@ static int amdgpu_vm_alloc_pts(struct 
amdgpu_device *adev,

  struct amdgpu_vm_pt *entry = cursor->entry;
  struct amdgpu_bo_param bp;
  struct amdgpu_bo *pt;
+    bool need_entries;
  int r;
  -    if (cursor->level < AMDGPU_VM_PTB && !entry->entries) {
+    need_entries = cursor->level < AMDGPU_VM_PTB && !entry->entries;
+    if (!need_entries && entry->base.bo)
+    return 0;
+
+    /* We need to make sure that we don't allocate PDs/PTs while 
holding the

+ * eviction lock or we run into lock recursion in the MM.
+ */
+    amdgpu_vm_eviction_unlock(vm);
+
+    if (need_entries) {
  unsigned num_entries;
    num_entries = amdgpu_vm_num_entries(adev, cursor->level);
  entry->entries = kvmalloc_array(num_entries,
  sizeof(*entry->entries),
  GFP_KERNEL | __GFP_ZERO);
-    if (!entry->entries)
-    return -ENOMEM;
+    if (!entry->entries) {
+    r = -ENOMEM;
+    goto error_lock;
+    }
  }
  -    if (entry->base.bo)
-    return 0;
+    if (entry->base.bo) {
+    r = 0;
+    goto error_lock;
+    }
    amdgpu_vm_bo_param(adev, vm, cursor->level, direct, );
    r = amdgpu_bo_create(adev, , );
+    amdgpu_vm_eviction_lock(vm);
  if (r)
-    return r;
+    goto error_free_pt;
    /* Keep a reference to the root directory to avoid
   * freeing them up in the wrong order.
@@ -936,6 +951,10 @@ static int amdgpu_vm_alloc_pts(struct 
amdgpu_device *adev,

  amdgpu_bo_unref();
  entry->base.bo = NULL;
  return r;
+
+error_lock:
+    amdgpu_vm_eviction_lock(vm);
+    return r;
  }
    /**


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

Re: [PATCH] drm/amdgpu: stop disable the scheduler during HW fini

[Deucher, Alexander]

[AMD Public Use]

Looks good to me.
Reviewed-by: Alex Deucher 

From: Christian König 
Sent: Thursday, February 27, 2020 9:50 AM
To: Das, Nirmoy ; amd-gfx@lists.freedesktop.org 
; Deucher, Alexander 
Subject: Re: [PATCH] drm/amdgpu: stop disable the scheduler during HW fini

Alex any comment on this?

Am 25.02.20 um 14:16 schrieb Nirmoy:
> Acked-by: Nirmoy Das 
>
> On 2/25/20 2:07 PM, Christian König wrote:
>> When we stop the HW for example for GPU reset we should not stop the
>> front-end scheduler. Otherwise we run into intermediate failures during
>> command submission.
>>
>> The scheduler should only be stopped in very few cases:
>> 1. We can't get the hardware working in ring or IB test after a GPU
>> reset.
>> 2. The KIQ scheduler is not used in the front-end and should be
>> disabled during GPU reset.
>> 3. In amdgpu_ring_fini() when the driver unloads.
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  2 --
>>   drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  8 
>>   drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  5 -
>>   drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  | 25 +
>>   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  7 ---
>>   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  9 -
>>   drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c |  3 ---
>>   drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  2 --
>>   drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  2 --
>>   drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |  4 
>>   drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |  3 ---
>>   drivers/gpu/drm/amd/amdgpu/si_dma.c|  1 -
>>   drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |  3 ---
>>   drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |  3 ---
>>   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |  3 ---
>>   drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |  7 ---
>>   drivers/gpu/drm/amd/amdgpu/vce_v4_0.c  |  4 
>>   drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  |  3 ---
>>   drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c  |  9 -
>>   drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c  | 11 +--
>>   20 files changed, 10 insertions(+), 104 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
>> b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
>> index 4274ccf765de..cb3b3a0a1348 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
>> @@ -320,8 +320,6 @@ static void cik_sdma_gfx_stop(struct
>> amdgpu_device *adev)
>>   WREG32(mmSDMA0_GFX_RB_CNTL + sdma_offsets[i], rb_cntl);
>>   WREG32(mmSDMA0_GFX_IB_CNTL + sdma_offsets[i], 0);
>>   }
>> -sdma0->sched.ready = false;
>> -sdma1->sched.ready = false;
>>   }
>> /**
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
>> index 7b6158320400..36ce67ce4800 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
>> @@ -2391,10 +2391,6 @@ static int gfx_v10_0_cp_gfx_enable(struct
>> amdgpu_device *adev, bool enable)
>>   tmp = REG_SET_FIELD(tmp, CP_ME_CNTL, ME_HALT, enable ? 0 : 1);
>>   tmp = REG_SET_FIELD(tmp, CP_ME_CNTL, PFP_HALT, enable ? 0 : 1);
>>   tmp = REG_SET_FIELD(tmp, CP_ME_CNTL, CE_HALT, enable ? 0 : 1);
>> -if (!enable) {
>> -for (i = 0; i < adev->gfx.num_gfx_rings; i++)
>> -adev->gfx.gfx_ring[i].sched.ready = false;
>> -}
>>   WREG32_SOC15(GC, 0, mmCP_ME_CNTL, tmp);
>> for (i = 0; i < adev->usec_timeout; i++) {
>> @@ -2869,16 +2865,12 @@ static int gfx_v10_0_cp_gfx_resume(struct
>> amdgpu_device *adev)
>> static void gfx_v10_0_cp_compute_enable(struct amdgpu_device
>> *adev, bool enable)
>>   {
>> -int i;
>> -
>>   if (enable) {
>>   WREG32_SOC15(GC, 0, mmCP_MEC_CNTL, 0);
>>   } else {
>>   WREG32_SOC15(GC, 0, mmCP_MEC_CNTL,
>>(CP_MEC_CNTL__MEC_ME1_HALT_MASK |
>> CP_MEC_CNTL__MEC_ME2_HALT_MASK));
>> -for (i = 0; i < adev->gfx.num_compute_rings; i++)
>> -adev->gfx.compute_ring[i].sched.ready = false;
>>   adev->gfx.kiq.ring.sched.ready = false;
>>   }
>>   udelay(50);
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>> index 31f44d05e606..e462a099dbda 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>> @@ -1950,7 +1950,6 @@ static int gfx_v6_0_ring_test_ib(struct
>> amdgpu_ring *ring, long timeout)
>> static void gfx_v6_0_cp_gfx_enable(struct amdgpu_device *adev,
>> bool enable)
>>   {
>> -int i;
>>   if (enable) {
>>   WREG32(mmCP_ME_CNTL, 0);
>>   } else {
>> @@ -1958,10 +1957,6 @@ static void gfx_v6_0_cp_gfx_enable(struct
>> amdgpu_device *adev, bool enable)
>> CP_ME_CNTL__PFP_HALT_MASK |
>> CP_ME_CNTL__CE_HALT_MASK));
>>   WREG32(mmSCRATCH_UMSK, 0);
>> -for (i = 0; i < adev->gfx.num_gfx_rings; 

Re: [PATCH 0/2] drm/amd/display: dc_link: cleaning up some code style issues

[Rodrigo Siqueira]

Hi Melissa,

First of all, thank you very much for this patchset; in general,
everything looks good to me.

I noticed that your patchset does not apply because you made your
changes based on `drm-misc-next`; when you send patches to amdgpu, use
the following repository:

 git://people.freedesktop.org/~agd5f/linux 

Could you prepare a V2?

Thanks!

On 02/26, Melissa Wen wrote:
> This patchset solves some coding style issues on dc_link for readability
> and cleaning up warnings. Change suggested by checkpatch.pl. 
> 
> Melissa Wen (2):
>   drm/amd/display: dc_link: code clean up on enable_link_dp function
>   drm/amd/display: dc_link: code clean up on detect_dp function
> 
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 67 +--
>  1 file changed, 32 insertions(+), 35 deletions(-)
> 
> -- 
> 2.25.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7C7a3e02e3f43447ed4fab08d7bb080d9b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183515885211986sdata=bnipkrUtKdO1oOKxdt1th4iIG1%2BBgl2wMPVrdmn3P1U%3Dreserved=0

-- 
Rodrigo Siqueira
https://siqueira.tech


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

Re: [PATCH 1/2] drm/amd/display: dc_link: code clean up on enable_link_dp function

[Rodrigo Siqueira]

Hi,

First of all, thank you for your patch.

I just have one tiny comment inline.

On 02/26, Melissa Wen wrote:
> Coding style clean up on enable_link_dp function as suggested by
> checkpatch.pl:
> 
> CHECK: Lines should not end with a '('
> WARNING: line over 80 characters
> WARNING: suspect code indent for conditional statements (8, 24)
> CHECK: braces {} should be used on all arms of this statement
> ERROR: else should follow close brace '}'
> CHECK: Comparison to NULL could be written
>"link->preferred_training_settings.fec_enable"
> 
> Signed-off-by: Melissa Wen 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 32 +--
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index a09119c10d7c..0f28b5694144 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -1480,9 +1480,8 @@ static void enable_stream_features(struct pipe_ctx 
> *pipe_ctx)
>   }
>  }
>  
> -static enum dc_status enable_link_dp(
> - struct dc_state *state,
> - struct pipe_ctx *pipe_ctx)
> +static enum dc_status enable_link_dp(struct dc_state *state,
> +  struct pipe_ctx *pipe_ctx)
>  {
>   struct dc_stream_state *stream = pipe_ctx->stream;
>   enum dc_status status;
> @@ -1512,27 +1511,28 @@ static enum dc_status enable_link_dp(
>  
>   pipe_ctx->stream_res.pix_clk_params.requested_sym_clk =
>   link_settings.link_rate * LINK_RATE_REF_FREQ_IN_KHZ;
> - if (state->clk_mgr && !apply_seamless_boot_optimization)
> - state->clk_mgr->funcs->update_clocks(state->clk_mgr, state, 
> false);
> + if (state->clk_mgr && !apply_seamless_boot_optimization) {
> + state->clk_mgr->funcs->update_clocks(state->clk_mgr,
> +  state, false);
> + }

This `if` condition only has one action, which means that you don't need
to add `{}` in the above statement. See:

https://www.kernel.org/doc/html/v4.10/process/coding-style.html#placing-braces-and-spaces

Thanks

>  
>   skip_video_pattern = true;
>  
>   if (link_settings.link_rate == LINK_RATE_LOW)
> - skip_video_pattern = false;
> -
> - if (perform_link_training_with_retries(
> - _settings,
> - skip_video_pattern,
> - LINK_TRAINING_ATTEMPTS,
> - pipe_ctx,
> - pipe_ctx->stream->signal)) {
> + skip_video_pattern = false;
> +
> + if (perform_link_training_with_retries(_settings,
> +skip_video_pattern,
> +LINK_TRAINING_ATTEMPTS,
> +pipe_ctx,
> +pipe_ctx->stream->signal)) {
>   link->cur_link_settings = link_settings;
>   status = DC_OK;
> - }
> - else
> + } else {
>   status = DC_FAIL_DP_LINK_TRAINING;
> + }
>  
> - if (link->preferred_training_settings.fec_enable != NULL)
> + if (link->preferred_training_settings.fec_enable)
>   fec_enable = *link->preferred_training_settings.fec_enable;
>   else
>   fec_enable = true;
> -- 
> 2.25.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7Ccbf2adb12548404e917208d7bb0842d2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183516476617662sdata=%2FyyxWqZVGvbVAnr1OWCKi0y5Sdl5j5Le6C3dmYoaNy4%3Dreserved=0

-- 
Rodrigo Siqueira
https://siqueira.tech


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

[PATCH] drm/amdgpu: don't enable runtime pm on navi12

[Alex Deucher]

BACO for power savings is not supported on navi12.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index c4f9d0e32383..eebf6ad04a78 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -176,7 +176,8 @@ int amdgpu_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
 (amdgpu_runtime_pm != 0) &&
 (adev->asic_type >= CHIP_TOPAZ) &&
 (adev->asic_type != CHIP_VEGA20) &&
-(adev->asic_type != CHIP_ARCTURUS)) /* enable runpm on VI+ */
+(adev->asic_type != CHIP_ARCTURUS) &&
+(adev->asic_type != CHIP_NAVI12)) /* enable runpm on VI+ */
adev->runpm = true;
else if (amdgpu_device_supports_baco(dev) &&
 (amdgpu_runtime_pm > 0))  /* enable runpm if runpm=1 on CI */
-- 
2.24.1

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

Re: [PATCH] drm/amdgpu: stop disable the scheduler during HW fini

[Christian König]

Alex any comment on this?

Am 25.02.20 um 14:16 schrieb Nirmoy:

Acked-by: Nirmoy Das 

On 2/25/20 2:07 PM, Christian König wrote:

When we stop the HW for example for GPU reset we should not stop the
front-end scheduler. Otherwise we run into intermediate failures during
command submission.

The scheduler should only be stopped in very few cases:
1. We can't get the hardware working in ring or IB test after a GPU 
reset.
2. The KIQ scheduler is not used in the front-end and should be 
disabled during GPU reset.

3. In amdgpu_ring_fini() when the driver unloads.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  2 --
  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  8 
  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  5 -
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  | 25 +
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  7 ---
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  9 -
  drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c |  3 ---
  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  2 --
  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  2 --
  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |  4 
  drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |  3 ---
  drivers/gpu/drm/amd/amdgpu/si_dma.c    |  1 -
  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |  3 ---
  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |  3 ---
  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |  3 ---
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |  7 ---
  drivers/gpu/drm/amd/amdgpu/vce_v4_0.c  |  4 
  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  |  3 ---
  drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c  |  9 -
  drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c  | 11 +--
  20 files changed, 10 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c 
b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c

index 4274ccf765de..cb3b3a0a1348 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
@@ -320,8 +320,6 @@ static void cik_sdma_gfx_stop(struct 
amdgpu_device *adev)

  WREG32(mmSDMA0_GFX_RB_CNTL + sdma_offsets[i], rb_cntl);
  WREG32(mmSDMA0_GFX_IB_CNTL + sdma_offsets[i], 0);
  }
-    sdma0->sched.ready = false;
-    sdma1->sched.ready = false;
  }
    /**
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c

index 7b6158320400..36ce67ce4800 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -2391,10 +2391,6 @@ static int gfx_v10_0_cp_gfx_enable(struct 
amdgpu_device *adev, bool enable)

  tmp = REG_SET_FIELD(tmp, CP_ME_CNTL, ME_HALT, enable ? 0 : 1);
  tmp = REG_SET_FIELD(tmp, CP_ME_CNTL, PFP_HALT, enable ? 0 : 1);
  tmp = REG_SET_FIELD(tmp, CP_ME_CNTL, CE_HALT, enable ? 0 : 1);
-    if (!enable) {
-    for (i = 0; i < adev->gfx.num_gfx_rings; i++)
-    adev->gfx.gfx_ring[i].sched.ready = false;
-    }
  WREG32_SOC15(GC, 0, mmCP_ME_CNTL, tmp);
    for (i = 0; i < adev->usec_timeout; i++) {
@@ -2869,16 +2865,12 @@ static int gfx_v10_0_cp_gfx_resume(struct 
amdgpu_device *adev)
    static void gfx_v10_0_cp_compute_enable(struct amdgpu_device 
*adev, bool enable)

  {
-    int i;
-
  if (enable) {
  WREG32_SOC15(GC, 0, mmCP_MEC_CNTL, 0);
  } else {
  WREG32_SOC15(GC, 0, mmCP_MEC_CNTL,
   (CP_MEC_CNTL__MEC_ME1_HALT_MASK |
    CP_MEC_CNTL__MEC_ME2_HALT_MASK));
-    for (i = 0; i < adev->gfx.num_compute_rings; i++)
-    adev->gfx.compute_ring[i].sched.ready = false;
  adev->gfx.kiq.ring.sched.ready = false;
  }
  udelay(50);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c

index 31f44d05e606..e462a099dbda 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
@@ -1950,7 +1950,6 @@ static int gfx_v6_0_ring_test_ib(struct 
amdgpu_ring *ring, long timeout)
    static void gfx_v6_0_cp_gfx_enable(struct amdgpu_device *adev, 
bool enable)

  {
-    int i;
  if (enable) {
  WREG32(mmCP_ME_CNTL, 0);
  } else {
@@ -1958,10 +1957,6 @@ static void gfx_v6_0_cp_gfx_enable(struct 
amdgpu_device *adev, bool enable)

    CP_ME_CNTL__PFP_HALT_MASK |
    CP_ME_CNTL__CE_HALT_MASK));
  WREG32(mmSCRATCH_UMSK, 0);
-    for (i = 0; i < adev->gfx.num_gfx_rings; i++)
-    adev->gfx.gfx_ring[i].sched.ready = false;
-    for (i = 0; i < adev->gfx.num_compute_rings; i++)
-    adev->gfx.compute_ring[i].sched.ready = false;
  }
  udelay(50);
  }
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c

index 8f20a5dd44fe..9bc8673c83ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -2431,15 +2431,12 @@ static int gfx_v7_0_ring_test_ib(struct 
amdgpu_ring *ring, long timeout)

   */
  static void gfx_v7_0_cp_gfx_enable(struct amdgpu_device 

Re: [PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

[Christian König]

Am 27.02.20 um 15:26 schrieb Yintian Tao:

If we release drm_device before amdgpu_driver_unload_kms,
then it will raise the error below. Therefore, we need to
place it before amdgpu_driver_unload_kms.
[   43.055736] Memory manager not clean during takedown.
[   43.055777] WARNING: CPU: 1 PID: 2807 at 
/build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/gpu/drm/drm_mm.c:913 
drm_mm_takedown+0x24/0x30 [drm]
[   43.055778] Modules linked in: amdgpu(OE-) amd_sched(OE) amdttm(OE) 
amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea 
sysfillrect sysimgblt snd_hda_codec_generic nfit kvm_intel kvm irqbypass 
crct10dif_pclmul crc32_pclmul snd_hda_intel snd_hda_codec snd_hda_core 
snd_hwdep snd_pcm ghash_clmulni_intel snd_seq_midi snd_seq_midi_event pcbc 
snd_rawmidi snd_seq snd_seq_device aesni_intel snd_timer joydev aes_x86_64 
crypto_simd cryptd glue_helper snd soundcore input_leds mac_hid serio_raw 
qemu_fw_cfg binfmt_misc sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace 
sunrpc parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic 
floppy usbhid psmouse hid i2c_piix4 e1000 pata_acpi
[   43.055819] CPU: 1 PID: 2807 Comm: modprobe Tainted: G   OE 
4.18.0-15-generic #16~18.04.1-Ubuntu
[   43.055820] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   43.055830] RIP: 0010:drm_mm_takedown+0x24/0x30 [drm]
[   43.055831] Code: 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 38 48 83 c7 38 48 39 
c7 75 02 f3 c3 55 48 c7 c7 38 33 80 c0 48 89 e5 e8 1c 41 ec d0 <0f> 0b 5d c3 0f 
1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
[   43.055857] RSP: 0018:ae33c1393d28 EFLAGS: 00010286
[   43.055859] RAX:  RBX: 9651b4a29800 RCX: 0006
[   43.055860] RDX: 0007 RSI: 0096 RDI: 9651bfc964b0
[   43.055861] RBP: ae33c1393d28 R08: 02a6 R09: 0004
[   43.055861] R10: ae33c1393d20 R11: 0001 R12: 9651ba6cb000
[   43.055863] R13: 9651b7f4 R14: c0de3a10 R15: 9651ba5c6460
[   43.055864] FS:  7f1d3c08d540() GS:9651bfc8() 
knlGS:
[   43.055865] CS:  0010 DS:  ES:  CR0: 80050033
[   43.055866] CR2: 5630a5831640 CR3: 00012e274004 CR4: 003606e0
[   43.055870] DR0:  DR1:  DR2: 
[   43.055871] DR3:  DR6: fffe0ff0 DR7: 0400
[   43.055871] Call Trace:
[   43.055885]  drm_vma_offset_manager_destroy+0x1b/0x30 [drm]
[   43.055894]  drm_gem_destroy+0x19/0x40 [drm]
[   43.055903]  drm_dev_fini+0x7f/0x90 [drm]
[   43.055911]  drm_dev_release+0x2b/0x40 [drm]
[   43.055919]  drm_dev_unplug+0x64/0x80 [drm]
[   43.055994]  amdgpu_pci_remove+0x39/0x70 [amdgpu]
[   43.055998]  pci_device_remove+0x3e/0xc0
[   43.056001]  device_release_driver_internal+0x18a/0x260
[   43.056003]  driver_detach+0x3f/0x80
[   43.056004]  bus_remove_driver+0x59/0xd0
[   43.056006]  driver_unregister+0x2c/0x40
[   43.056008]  pci_unregister_driver+0x22/0xa0
[   43.056087]  amdgpu_exit+0x15/0x57c [amdgpu]
[   43.056090]  __x64_sys_delete_module+0x146/0x280
[   43.056094]  do_syscall_64+0x5a/0x120

v2: put drm_dev_put after pci_set_drvdata

Signed-off-by: Yintian Tao 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 02d80b9dbfe1..bec4337156a7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1138,10 +1138,10 @@ amdgpu_pci_remove(struct pci_dev *pdev)
  #endif
DRM_ERROR("Hotplug removal is not supported\n");
drm_dev_unplug(dev);
-   drm_dev_put(dev);
amdgpu_driver_unload_kms(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
+   drm_dev_put(dev);
  }
  
  static void


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

Re: [PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

[Alex Deucher]

On Thu, Feb 27, 2020 at 9:26 AM Yintian Tao  wrote:
>
> If we release drm_device before amdgpu_driver_unload_kms,
> then it will raise the error below. Therefore, we need to
> place it before amdgpu_driver_unload_kms.
> [   43.055736] Memory manager not clean during takedown.
> [   43.055777] WARNING: CPU: 1 PID: 2807 at 
> /build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/gpu/drm/drm_mm.c:913 
> drm_mm_takedown+0x24/0x30 [drm]
> [   43.055778] Modules linked in: amdgpu(OE-) amd_sched(OE) amdttm(OE) 
> amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops 
> syscopyarea sysfillrect sysimgblt snd_hda_codec_generic nfit kvm_intel kvm 
> irqbypass crct10dif_pclmul crc32_pclmul snd_hda_intel snd_hda_codec 
> snd_hda_core snd_hwdep snd_pcm ghash_clmulni_intel snd_seq_midi 
> snd_seq_midi_event pcbc snd_rawmidi snd_seq snd_seq_device aesni_intel 
> snd_timer joydev aes_x86_64 crypto_simd cryptd glue_helper snd soundcore 
> input_leds mac_hid serio_raw qemu_fw_cfg binfmt_misc sch_fq_codel nfsd 
> auth_rpcgss nfs_acl lockd grace sunrpc parport_pc ppdev lp parport ip_tables 
> x_tables autofs4 hid_generic floppy usbhid psmouse hid i2c_piix4 e1000 
> pata_acpi
> [   43.055819] CPU: 1 PID: 2807 Comm: modprobe Tainted: G   OE 
> 4.18.0-15-generic #16~18.04.1-Ubuntu
> [   43.055820] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.12.0-1 04/01/2014
> [   43.055830] RIP: 0010:drm_mm_takedown+0x24/0x30 [drm]
> [   43.055831] Code: 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 38 48 83 c7 38 
> 48 39 c7 75 02 f3 c3 55 48 c7 c7 38 33 80 c0 48 89 e5 e8 1c 41 ec d0 <0f> 0b 
> 5d c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
> [   43.055857] RSP: 0018:ae33c1393d28 EFLAGS: 00010286
> [   43.055859] RAX:  RBX: 9651b4a29800 RCX: 
> 0006
> [   43.055860] RDX: 0007 RSI: 0096 RDI: 
> 9651bfc964b0
> [   43.055861] RBP: ae33c1393d28 R08: 02a6 R09: 
> 0004
> [   43.055861] R10: ae33c1393d20 R11: 0001 R12: 
> 9651ba6cb000
> [   43.055863] R13: 9651b7f4 R14: c0de3a10 R15: 
> 9651ba5c6460
> [   43.055864] FS:  7f1d3c08d540() GS:9651bfc8() 
> knlGS:
> [   43.055865] CS:  0010 DS:  ES:  CR0: 80050033
> [   43.055866] CR2: 5630a5831640 CR3: 00012e274004 CR4: 
> 003606e0
> [   43.055870] DR0:  DR1:  DR2: 
> 
> [   43.055871] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   43.055871] Call Trace:
> [   43.055885]  drm_vma_offset_manager_destroy+0x1b/0x30 [drm]
> [   43.055894]  drm_gem_destroy+0x19/0x40 [drm]
> [   43.055903]  drm_dev_fini+0x7f/0x90 [drm]
> [   43.055911]  drm_dev_release+0x2b/0x40 [drm]
> [   43.055919]  drm_dev_unplug+0x64/0x80 [drm]
> [   43.055994]  amdgpu_pci_remove+0x39/0x70 [amdgpu]
> [   43.055998]  pci_device_remove+0x3e/0xc0
> [   43.056001]  device_release_driver_internal+0x18a/0x260
> [   43.056003]  driver_detach+0x3f/0x80
> [   43.056004]  bus_remove_driver+0x59/0xd0
> [   43.056006]  driver_unregister+0x2c/0x40
> [   43.056008]  pci_unregister_driver+0x22/0xa0
> [   43.056087]  amdgpu_exit+0x15/0x57c [amdgpu]
> [   43.056090]  __x64_sys_delete_module+0x146/0x280
> [   43.056094]  do_syscall_64+0x5a/0x120
>
> v2: put drm_dev_put after pci_set_drvdata
>
> Signed-off-by: Yintian Tao 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 02d80b9dbfe1..bec4337156a7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1138,10 +1138,10 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>  #endif
> DRM_ERROR("Hotplug removal is not supported\n");
> drm_dev_unplug(dev);
> -   drm_dev_put(dev);
> amdgpu_driver_unload_kms(dev);
> pci_disable_device(pdev);
> pci_set_drvdata(pdev, NULL);
> +   drm_dev_put(dev);
>  }
>
>  static void
> --
> 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] drm/amdgpu: no need to clean debugfs at amdgpu

[Alex Deucher]

On Thu, Feb 27, 2020 at 7:46 AM Yintian Tao  wrote:
>
> drm_minor_unregister will invoke drm_debugfs_cleanup
> to clean all the child node under primary minor node.
> We don't need to invoke amdgpu_debugfs_fini and
> amdgpu_debugfs_regs_cleanup to clean agian.
> Otherwise, it will raise the NULL pointer like below.
> [   45.046029] BUG: unable to handle kernel NULL pointer dereference at 
> 00a8
> [   45.047256] PGD 0 P4D 0
> [   45.047713] Oops: 0002 [#1] SMP PTI
> [   45.048198] CPU: 0 PID: 2796 Comm: modprobe Tainted: GW  OE 
> 4.18.0-15-generic #16~18.04.1-Ubuntu
> [   45.049538] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.12.0-1 04/01/2014
> [   45.050651] RIP: 0010:down_write+0x1f/0x40
> [   45.051194] Code: 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 
> e5 53 48 89 fb e8 ce d9 ff ff 48 ba 01 00 00 00 ff ff ff ff 48 89 d8  48 
> 0f c1 10 85 d2 74 05 e8 53 1c ff ff 65 48 8b 04 25 00 5c 01
> [   45.053702] RSP: 0018:ad8f4133fd40 EFLAGS: 00010246
> [   45.054384] RAX: 00a8 RBX: 00a8 RCX: 
> a011327dd814
> [   45.055349] RDX: 0001 RSI: 0001 RDI: 
> 00a8
> [   45.056346] RBP: ad8f4133fd48 R08:  R09: 
> c0690a00
> [   45.057326] R10: ad8f4133fd58 R11: 0001 R12: 
> a0113cff0300
> [   45.058266] R13: a0113c0a R14: c0c02a10 R15: 
> a0113e5c7860
> [   45.059221] FS:  7f60d46f9540() GS:a0113fc0() 
> knlGS:
> [   45.060809] CS:  0010 DS:  ES:  CR0: 80050033
> [   45.061826] CR2: 00a8 CR3: 000136250004 CR4: 
> 003606f0
> [   45.062913] DR0:  DR1:  DR2: 
> 
> [   45.064404] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   45.065897] Call Trace:
> [   45.066426]  debugfs_remove+0x36/0xa0
> [   45.067131]  amdgpu_debugfs_ring_fini+0x15/0x20 [amdgpu]
> [   45.068019]  amdgpu_debugfs_fini+0x2c/0x50 [amdgpu]
> [   45.068756]  amdgpu_pci_remove+0x49/0x70 [amdgpu]
> [   45.069439]  pci_device_remove+0x3e/0xc0
> [   45.070037]  device_release_driver_internal+0x18a/0x260
> [   45.070842]  driver_detach+0x3f/0x80
> [   45.071325]  bus_remove_driver+0x59/0xd0
> [   45.071850]  driver_unregister+0x2c/0x40
> [   45.072377]  pci_unregister_driver+0x22/0xa0
> [   45.073043]  amdgpu_exit+0x15/0x57c [amdgpu]
> [   45.073683]  __x64_sys_delete_module+0x146/0x280
> [   45.074369]  do_syscall_64+0x5a/0x120
> [   45.074916]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> v2: remove all debugfs cleanup/fini code at amdgpu
>
> Signed-off-by: Yintian Tao 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 30 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c|  7 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  1 -
>  7 files changed, 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 3bb74056b9d2..abc148280ba5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -992,18 +992,6 @@ int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
> return 0;
>  }
>
> -void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev)
> -{
> -   unsigned i;
> -
> -   for (i = 0; i < ARRAY_SIZE(debugfs_regs); i++) {
> -   if (adev->debugfs_regs[i]) {
> -   debugfs_remove(adev->debugfs_regs[i]);
> -   adev->debugfs_regs[i] = NULL;
> -   }
> -   }
> -}
> -
>  static int amdgpu_debugfs_test_ib(struct seq_file *m, void *data)
>  {
> struct drm_info_node *node = (struct drm_info_node *) m->private;
> @@ -1339,31 +1327,13 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
> ARRAY_SIZE(amdgpu_debugfs_list));
>  }
>
> -void amdgpu_debugfs_fini(struct amdgpu_device *adev)
> -{
> -   int i;
> -
> -   for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> -   struct amdgpu_ring *ring = adev->rings[i];
> -
> -   if (!ring)
> -   continue;
> -
> -   amdgpu_debugfs_ring_fini(ring);
> -   }
> -   amdgpu_ttm_debugfs_fini(adev);
> -   debugfs_remove(adev->debugfs_preempt);
> -}
> -
>  #else
>  int amdgpu_debugfs_init(struct amdgpu_device *adev)
>  {
> return 0;
>  }
> -void amdgpu_debugfs_fini(struct amdgpu_device *adev) { }
>  int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
>  {
> return 0;
>  }
> -void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev) { }
>  #endif
> diff --git 

Re: [PATCH] drm/amdgpu: miss to remove pp_sclk file

[Alex Deucher]

On Thu, Feb 27, 2020 at 9:11 AM Yintian Tao  wrote:
>
> Miss to remove pp_sclk file
>
> Signed-off-by: Yintian Tao 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index 9deff8cc9723..a43fc1c8ffd0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -3471,6 +3471,7 @@ void amdgpu_pm_sysfs_fini(struct amdgpu_device *adev)
> device_remove_file(adev->dev, _attr_pp_cur_state);
> device_remove_file(adev->dev, _attr_pp_force_state);
> device_remove_file(adev->dev, _attr_pp_table);
> +   device_remove_file(adev->dev, _attr_pp_sclk);
>
> device_remove_file(adev->dev, _attr_pp_dpm_sclk);
> device_remove_file(adev->dev, _attr_pp_dpm_mclk);
> --
> 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: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

[Alex Deucher]

On Thu, Feb 27, 2020 at 5:08 AM Christian König
 wrote:
>
> Am 26.02.20 um 21:37 schrieb Nirmoy Das:
> > We were changing compute ring priority while rings were being used
> > before every job submission which is not recommended. This patch
> > recreates entity with higher/normal priority sched list when user
> > changes ctx's priority.
> >
> > high/normal priority sched list are generated from set of high/normal
> > priority compute queues. When there are no high priority hw queues then
> > it fall backs to software priority.
> >
> > Signed-off-by: Nirmoy Das 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  4 --
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 58 ++--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h  |  2 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  6 ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c |  4 ++
> >   5 files changed, 59 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index f397ff97b4e4..8304d0c87899 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -1205,7 +1205,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser 
> > *p,
> >   struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> >   struct drm_sched_entity *entity = p->entity;
> >   enum drm_sched_priority priority;
> > - struct amdgpu_ring *ring;
> >   struct amdgpu_bo_list_entry *e;
> >   struct amdgpu_job *job;
> >   uint64_t seq;
> > @@ -1258,9 +1257,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser 
> > *p,
> >   priority = job->base.s_priority;
> >   drm_sched_entity_push_job(>base, entity);
> >
> > - ring = to_amdgpu_ring(entity->rq->sched);
> > - amdgpu_ring_priority_get(ring, priority);
> > -
> >   amdgpu_vm_move_to_lru_tail(p->adev, >vm);
> >
> >   ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > index 94a6c42f29ea..ea4dc57d2237 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > @@ -85,8 +85,13 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx 
> > *ctx, const u32 hw_ip, const
> >   num_scheds = 1;
> >   break;
> >   case AMDGPU_HW_IP_COMPUTE:
> > - scheds = adev->gfx.compute_sched;
> > - num_scheds = adev->gfx.num_compute_sched;
> > + if (priority <= DRM_SCHED_PRIORITY_NORMAL) {
> > + scheds = adev->gfx.compute_sched;
> > + num_scheds = adev->gfx.num_compute_sched;
> > + } else {
> > + scheds = adev->gfx.compute_sched_high;
> > + num_scheds = adev->gfx.num_compute_sched_high;
> > + }
> >   break;
> >   case AMDGPU_HW_IP_DMA:
> >   scheds = adev->sdma.sdma_sched;
> > @@ -502,6 +507,24 @@ struct dma_fence *amdgpu_ctx_get_fence(struct 
> > amdgpu_ctx *ctx,
> >   return fence;
> >   }
> >
> > +static void amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx,
> > + const u32 hw_ip,
> > + enum drm_sched_priority priority)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < amdgpu_ctx_num_entities[hw_ip]; ++i) {
> > + if (!ctx->entities[hw_ip][i])
> > + continue;
> > +
> > + /* TODO what happens with prev scheduled jobs */
>
> If we do it right, that should be unproblematic.
>
> The entity changes the rq/scheduler it submits stuff to only when it is
> idle, e.g. no jobs on the hardware nor software queue.
>
> So changing the priority when there is still work should be ok because
> it won't take effect until the entity is idle.
>
> Can of course be that userspace then wonders why the new priority
> doesn't take effect. But when you shoot yourself into the foot it is
> supposed to hurt, doesn't it?
>
> > + drm_sched_entity_destroy(>entities[hw_ip][i]->entity);
> > + amdgpu_ctx_fini_entity(ctx->entities[hw_ip][i]);
> > +
> > + amdgpu_ctx_init_entity(ctx, AMDGPU_HW_IP_COMPUTE, i);
>
> Well, that is most likely NOT the right way of doing it :) Destroying
> the entity with fini and reinit might cause quite a bunch of problems.
>
> Could be that this works as well, but I would rather just assign
> sched_list and num_sched_list.
>
> > +
> > + }
> > +}
> >   void amdgpu_ctx_priority_override(struct amdgpu_ctx *ctx,
> > enum drm_sched_priority priority)
> >   {
> > @@ -515,12 +538,18 @@ void amdgpu_ctx_priority_override(struct amdgpu_ctx 
> > *ctx,
> >   for (i = 0; i < 

[PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

[Yintian Tao]

If we release drm_device before amdgpu_driver_unload_kms,
then it will raise the error below. Therefore, we need to
place it before amdgpu_driver_unload_kms.
[   43.055736] Memory manager not clean during takedown.
[   43.055777] WARNING: CPU: 1 PID: 2807 at 
/build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/gpu/drm/drm_mm.c:913 
drm_mm_takedown+0x24/0x30 [drm]
[   43.055778] Modules linked in: amdgpu(OE-) amd_sched(OE) amdttm(OE) 
amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea 
sysfillrect sysimgblt snd_hda_codec_generic nfit kvm_intel kvm irqbypass 
crct10dif_pclmul crc32_pclmul snd_hda_intel snd_hda_codec snd_hda_core 
snd_hwdep snd_pcm ghash_clmulni_intel snd_seq_midi snd_seq_midi_event pcbc 
snd_rawmidi snd_seq snd_seq_device aesni_intel snd_timer joydev aes_x86_64 
crypto_simd cryptd glue_helper snd soundcore input_leds mac_hid serio_raw 
qemu_fw_cfg binfmt_misc sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace 
sunrpc parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic 
floppy usbhid psmouse hid i2c_piix4 e1000 pata_acpi
[   43.055819] CPU: 1 PID: 2807 Comm: modprobe Tainted: G   OE 
4.18.0-15-generic #16~18.04.1-Ubuntu
[   43.055820] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   43.055830] RIP: 0010:drm_mm_takedown+0x24/0x30 [drm]
[   43.055831] Code: 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 38 48 83 c7 38 
48 39 c7 75 02 f3 c3 55 48 c7 c7 38 33 80 c0 48 89 e5 e8 1c 41 ec d0 <0f> 0b 5d 
c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
[   43.055857] RSP: 0018:ae33c1393d28 EFLAGS: 00010286
[   43.055859] RAX:  RBX: 9651b4a29800 RCX: 0006
[   43.055860] RDX: 0007 RSI: 0096 RDI: 9651bfc964b0
[   43.055861] RBP: ae33c1393d28 R08: 02a6 R09: 0004
[   43.055861] R10: ae33c1393d20 R11: 0001 R12: 9651ba6cb000
[   43.055863] R13: 9651b7f4 R14: c0de3a10 R15: 9651ba5c6460
[   43.055864] FS:  7f1d3c08d540() GS:9651bfc8() 
knlGS:
[   43.055865] CS:  0010 DS:  ES:  CR0: 80050033
[   43.055866] CR2: 5630a5831640 CR3: 00012e274004 CR4: 003606e0
[   43.055870] DR0:  DR1:  DR2: 
[   43.055871] DR3:  DR6: fffe0ff0 DR7: 0400
[   43.055871] Call Trace:
[   43.055885]  drm_vma_offset_manager_destroy+0x1b/0x30 [drm]
[   43.055894]  drm_gem_destroy+0x19/0x40 [drm]
[   43.055903]  drm_dev_fini+0x7f/0x90 [drm]
[   43.055911]  drm_dev_release+0x2b/0x40 [drm]
[   43.055919]  drm_dev_unplug+0x64/0x80 [drm]
[   43.055994]  amdgpu_pci_remove+0x39/0x70 [amdgpu]
[   43.055998]  pci_device_remove+0x3e/0xc0
[   43.056001]  device_release_driver_internal+0x18a/0x260
[   43.056003]  driver_detach+0x3f/0x80
[   43.056004]  bus_remove_driver+0x59/0xd0
[   43.056006]  driver_unregister+0x2c/0x40
[   43.056008]  pci_unregister_driver+0x22/0xa0
[   43.056087]  amdgpu_exit+0x15/0x57c [amdgpu]
[   43.056090]  __x64_sys_delete_module+0x146/0x280
[   43.056094]  do_syscall_64+0x5a/0x120

v2: put drm_dev_put after pci_set_drvdata

Signed-off-by: Yintian Tao 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 02d80b9dbfe1..bec4337156a7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1138,10 +1138,10 @@ amdgpu_pci_remove(struct pci_dev *pdev)
 #endif
DRM_ERROR("Hotplug removal is not supported\n");
drm_dev_unplug(dev);
-   drm_dev_put(dev);
amdgpu_driver_unload_kms(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
+   drm_dev_put(dev);
 }
 
 static void
-- 
2.17.1

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

RE: [PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

[Tao, Yintian]

Many thanks. I will put it after pci_* functions.

-Original Message-
From: Christian König  
Sent: 2020年2月27日 22:21
To: Tao, Yintian ; Koenig, Christian 
; Deucher, Alexander 
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: release drm_device after 
amdgpu_driver_unload_kms

Am 27.02.20 um 12:58 schrieb Yintian Tao:
> If we release drm_device before amdgpu_driver_unload_kms, then it will 
> raise the error below. Therefore, we need to place it before 
> amdgpu_driver_unload_kms.
> [   43.055736] Memory manager not clean during takedown.
> [   43.055777] WARNING: CPU: 1 PID: 2807 at 
> /build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/gpu/drm/drm_mm.c:913 
> drm_mm_takedown+0x24/0x30 [drm]
> [   43.055778] Modules linked in: amdgpu(OE-) amd_sched(OE) amdttm(OE) 
> amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops 
> syscopyarea sysfillrect sysimgblt snd_hda_codec_generic nfit kvm_intel kvm 
> irqbypass crct10dif_pclmul crc32_pclmul snd_hda_intel snd_hda_codec 
> snd_hda_core snd_hwdep snd_pcm ghash_clmulni_intel snd_seq_midi 
> snd_seq_midi_event pcbc snd_rawmidi snd_seq snd_seq_device aesni_intel 
> snd_timer joydev aes_x86_64 crypto_simd cryptd glue_helper snd soundcore 
> input_leds mac_hid serio_raw qemu_fw_cfg binfmt_misc sch_fq_codel nfsd 
> auth_rpcgss nfs_acl lockd grace sunrpc parport_pc ppdev lp parport ip_tables 
> x_tables autofs4 hid_generic floppy usbhid psmouse hid i2c_piix4 e1000 
> pata_acpi
> [   43.055819] CPU: 1 PID: 2807 Comm: modprobe Tainted: G   OE 
> 4.18.0-15-generic #16~18.04.1-Ubuntu
> [   43.055820] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.12.0-1 04/01/2014
> [   43.055830] RIP: 0010:drm_mm_takedown+0x24/0x30 [drm]
> [   43.055831] Code: 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 38 48 83 c7 38 
> 48 39 c7 75 02 f3 c3 55 48 c7 c7 38 33 80 c0 48 89 e5 e8 1c 41 ec d0 <0f> 0b 
> 5d c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
> [   43.055857] RSP: 0018:ae33c1393d28 EFLAGS: 00010286
> [   43.055859] RAX:  RBX: 9651b4a29800 RCX: 
> 0006
> [   43.055860] RDX: 0007 RSI: 0096 RDI: 
> 9651bfc964b0
> [   43.055861] RBP: ae33c1393d28 R08: 02a6 R09: 
> 0004
> [   43.055861] R10: ae33c1393d20 R11: 0001 R12: 
> 9651ba6cb000
> [   43.055863] R13: 9651b7f4 R14: c0de3a10 R15: 
> 9651ba5c6460
> [   43.055864] FS:  7f1d3c08d540() GS:9651bfc8() 
> knlGS:
> [   43.055865] CS:  0010 DS:  ES:  CR0: 80050033
> [   43.055866] CR2: 5630a5831640 CR3: 00012e274004 CR4: 
> 003606e0
> [   43.055870] DR0:  DR1:  DR2: 
> 
> [   43.055871] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   43.055871] Call Trace:
> [   43.055885]  drm_vma_offset_manager_destroy+0x1b/0x30 [drm]
> [   43.055894]  drm_gem_destroy+0x19/0x40 [drm]
> [   43.055903]  drm_dev_fini+0x7f/0x90 [drm]
> [   43.055911]  drm_dev_release+0x2b/0x40 [drm]
> [   43.055919]  drm_dev_unplug+0x64/0x80 [drm]
> [   43.055994]  amdgpu_pci_remove+0x39/0x70 [amdgpu]
> [   43.055998]  pci_device_remove+0x3e/0xc0
> [   43.056001]  device_release_driver_internal+0x18a/0x260
> [   43.056003]  driver_detach+0x3f/0x80
> [   43.056004]  bus_remove_driver+0x59/0xd0
> [   43.056006]  driver_unregister+0x2c/0x40
> [   43.056008]  pci_unregister_driver+0x22/0xa0
> [   43.056087]  amdgpu_exit+0x15/0x57c [amdgpu]
> [   43.056090]  __x64_sys_delete_module+0x146/0x280
> [   43.056094]  do_syscall_64+0x5a/0x120
>
> Signed-off-by: Yintian Tao 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 02d80b9dbfe1..01a1082b5cab 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1138,8 +1138,8 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>   #endif
>   DRM_ERROR("Hotplug removal is not supported\n");
>   drm_dev_unplug(dev);
> - drm_dev_put(dev);
>   amdgpu_driver_unload_kms(dev);
> + drm_dev_put(dev);
>   pci_disable_device(pdev);
>   pci_set_drvdata(pdev, NULL);

Maybe even put this after the pci_* functions?

At least pci_set_drvdata() sounds like it needs to come before we release the 
structure.

Christian.

>   }

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

Re: [PATCH] drm/amdgpu/sriov: Use VF-accessible register for gpu_clock_count

[Deucher, Alexander]

[AMD Public Use]

Is there any reason to not just use this for bare metal as well?

Alex


From: amd-gfx  on behalf of jianzh 

Sent: Thursday, February 27, 2020 6:21 AM
To: amd-gfx@lists.freedesktop.org 
Cc: Deng, Emily ; Zhao, Jiange ; Liu, 
Monk 
Subject: [PATCH] drm/amdgpu/sriov: Use VF-accessible register for 
gpu_clock_count

Navi12 VK CTS subtest timestamp.calibrated.dev_domain_test failed
because mmRLC_CAPTURE_GPU_CLOCK_COUNT register cannot be
written in VF due to security policy.

Solution: use a VF-accessible timestamp register pair
mmGOLDEN_TSC_COUNT_LOWER/UPPER for SRIOV case.

Signed-off-by: jianzh 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 44f00ec..8787a46 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -35,6 +35,8 @@

 #include "gc/gc_10_1_0_offset.h"
 #include "gc/gc_10_1_0_sh_mask.h"
+#include "smuio/smuio_11_0_0_offset.h"
+#include "smuio/smuio_11_0_0_sh_mask.h"
 #include "navi10_enum.h"
 #include "hdp/hdp_5_0_0_offset.h"
 #include "ivsrcid/gfx/irqsrcs_gfx_10_1.h"
@@ -3920,9 +3922,14 @@ static uint64_t gfx_v10_0_get_gpu_clock_counter(struct 
amdgpu_device *adev)

 amdgpu_gfx_off_ctrl(adev, false);
 mutex_lock(>gfx.gpu_clock_mutex);
-   WREG32_SOC15(GC, 0, mmRLC_CAPTURE_GPU_CLOCK_COUNT, 1);
-   clock = (uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_LSB) |
-   ((uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_MSB) << 
32ULL);
+   if (!amdgpu_sriov_vf(adev)) {
+   WREG32_SOC15(GC, 0, mmRLC_CAPTURE_GPU_CLOCK_COUNT, 1);
+   clock = (uint64_t)RREG32_SOC15(GC, 0, 
mmRLC_GPU_CLOCK_COUNT_LSB) |
+   ((uint64_t)RREG32_SOC15(GC, 0, 
mmRLC_GPU_CLOCK_COUNT_MSB) << 32ULL);
+   } else {
+   clock = (uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER) |
+   ((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER) << 32ULL);
+   }
 mutex_unlock(>gfx.gpu_clock_mutex);
 amdgpu_gfx_off_ctrl(adev, true);
 return clock;
--
2.7.4

___
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-gfxdata=02%7C01%7Calexander.deucher%40amd.com%7C9b14a49e41fd48f7138f08d7bb773ed9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183993593225894sdata=jFUVpgeEcTTJbTJ3a7ibAPOyAU3RVF%2FEIN41zaqS0eM%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

[Christian König]

Am 27.02.20 um 12:58 schrieb Yintian Tao:

If we release drm_device before amdgpu_driver_unload_kms,
then it will raise the error below. Therefore, we need to
place it before amdgpu_driver_unload_kms.
[   43.055736] Memory manager not clean during takedown.
[   43.055777] WARNING: CPU: 1 PID: 2807 at 
/build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/gpu/drm/drm_mm.c:913 
drm_mm_takedown+0x24/0x30 [drm]
[   43.055778] Modules linked in: amdgpu(OE-) amd_sched(OE) amdttm(OE) 
amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea 
sysfillrect sysimgblt snd_hda_codec_generic nfit kvm_intel kvm irqbypass 
crct10dif_pclmul crc32_pclmul snd_hda_intel snd_hda_codec snd_hda_core 
snd_hwdep snd_pcm ghash_clmulni_intel snd_seq_midi snd_seq_midi_event pcbc 
snd_rawmidi snd_seq snd_seq_device aesni_intel snd_timer joydev aes_x86_64 
crypto_simd cryptd glue_helper snd soundcore input_leds mac_hid serio_raw 
qemu_fw_cfg binfmt_misc sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace 
sunrpc parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic 
floppy usbhid psmouse hid i2c_piix4 e1000 pata_acpi
[   43.055819] CPU: 1 PID: 2807 Comm: modprobe Tainted: G   OE 
4.18.0-15-generic #16~18.04.1-Ubuntu
[   43.055820] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   43.055830] RIP: 0010:drm_mm_takedown+0x24/0x30 [drm]
[   43.055831] Code: 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 38 48 83 c7 38 48 39 
c7 75 02 f3 c3 55 48 c7 c7 38 33 80 c0 48 89 e5 e8 1c 41 ec d0 <0f> 0b 5d c3 0f 
1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
[   43.055857] RSP: 0018:ae33c1393d28 EFLAGS: 00010286
[   43.055859] RAX:  RBX: 9651b4a29800 RCX: 0006
[   43.055860] RDX: 0007 RSI: 0096 RDI: 9651bfc964b0
[   43.055861] RBP: ae33c1393d28 R08: 02a6 R09: 0004
[   43.055861] R10: ae33c1393d20 R11: 0001 R12: 9651ba6cb000
[   43.055863] R13: 9651b7f4 R14: c0de3a10 R15: 9651ba5c6460
[   43.055864] FS:  7f1d3c08d540() GS:9651bfc8() 
knlGS:
[   43.055865] CS:  0010 DS:  ES:  CR0: 80050033
[   43.055866] CR2: 5630a5831640 CR3: 00012e274004 CR4: 003606e0
[   43.055870] DR0:  DR1:  DR2: 
[   43.055871] DR3:  DR6: fffe0ff0 DR7: 0400
[   43.055871] Call Trace:
[   43.055885]  drm_vma_offset_manager_destroy+0x1b/0x30 [drm]
[   43.055894]  drm_gem_destroy+0x19/0x40 [drm]
[   43.055903]  drm_dev_fini+0x7f/0x90 [drm]
[   43.055911]  drm_dev_release+0x2b/0x40 [drm]
[   43.055919]  drm_dev_unplug+0x64/0x80 [drm]
[   43.055994]  amdgpu_pci_remove+0x39/0x70 [amdgpu]
[   43.055998]  pci_device_remove+0x3e/0xc0
[   43.056001]  device_release_driver_internal+0x18a/0x260
[   43.056003]  driver_detach+0x3f/0x80
[   43.056004]  bus_remove_driver+0x59/0xd0
[   43.056006]  driver_unregister+0x2c/0x40
[   43.056008]  pci_unregister_driver+0x22/0xa0
[   43.056087]  amdgpu_exit+0x15/0x57c [amdgpu]
[   43.056090]  __x64_sys_delete_module+0x146/0x280
[   43.056094]  do_syscall_64+0x5a/0x120

Signed-off-by: Yintian Tao 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 02d80b9dbfe1..01a1082b5cab 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1138,8 +1138,8 @@ amdgpu_pci_remove(struct pci_dev *pdev)
  #endif
DRM_ERROR("Hotplug removal is not supported\n");
drm_dev_unplug(dev);
-   drm_dev_put(dev);
amdgpu_driver_unload_kms(dev);
+   drm_dev_put(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);


Maybe even put this after the pci_* functions?

At least pci_set_drvdata() sounds like it needs to come before we 
release the structure.


Christian.


  }


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

Re: [PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

[Christian König]

Am 27.02.20 um 13:46 schrieb Yintian Tao:

drm_minor_unregister will invoke drm_debugfs_cleanup
to clean all the child node under primary minor node.
We don't need to invoke amdgpu_debugfs_fini and
amdgpu_debugfs_regs_cleanup to clean agian.
Otherwise, it will raise the NULL pointer like below.
[   45.046029] BUG: unable to handle kernel NULL pointer dereference at 
00a8
[   45.047256] PGD 0 P4D 0
[   45.047713] Oops: 0002 [#1] SMP PTI
[   45.048198] CPU: 0 PID: 2796 Comm: modprobe Tainted: GW  OE 
4.18.0-15-generic #16~18.04.1-Ubuntu
[   45.049538] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   45.050651] RIP: 0010:down_write+0x1f/0x40
[   45.051194] Code: 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 
48 89 fb e8 ce d9 ff ff 48 ba 01 00 00 00 ff ff ff ff 48 89 d8  48 0f c1 10 
85 d2 74 05 e8 53 1c ff ff 65 48 8b 04 25 00 5c 01
[   45.053702] RSP: 0018:ad8f4133fd40 EFLAGS: 00010246
[   45.054384] RAX: 00a8 RBX: 00a8 RCX: a011327dd814
[   45.055349] RDX: 0001 RSI: 0001 RDI: 00a8
[   45.056346] RBP: ad8f4133fd48 R08:  R09: c0690a00
[   45.057326] R10: ad8f4133fd58 R11: 0001 R12: a0113cff0300
[   45.058266] R13: a0113c0a R14: c0c02a10 R15: a0113e5c7860
[   45.059221] FS:  7f60d46f9540() GS:a0113fc0() 
knlGS:
[   45.060809] CS:  0010 DS:  ES:  CR0: 80050033
[   45.061826] CR2: 00a8 CR3: 000136250004 CR4: 003606f0
[   45.062913] DR0:  DR1:  DR2: 
[   45.064404] DR3:  DR6: fffe0ff0 DR7: 0400
[   45.065897] Call Trace:
[   45.066426]  debugfs_remove+0x36/0xa0
[   45.067131]  amdgpu_debugfs_ring_fini+0x15/0x20 [amdgpu]
[   45.068019]  amdgpu_debugfs_fini+0x2c/0x50 [amdgpu]
[   45.068756]  amdgpu_pci_remove+0x49/0x70 [amdgpu]
[   45.069439]  pci_device_remove+0x3e/0xc0
[   45.070037]  device_release_driver_internal+0x18a/0x260
[   45.070842]  driver_detach+0x3f/0x80
[   45.071325]  bus_remove_driver+0x59/0xd0
[   45.071850]  driver_unregister+0x2c/0x40
[   45.072377]  pci_unregister_driver+0x22/0xa0
[   45.073043]  amdgpu_exit+0x15/0x57c [amdgpu]
[   45.073683]  __x64_sys_delete_module+0x146/0x280
[   45.074369]  do_syscall_64+0x5a/0x120
[   45.074916]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

v2: remove all debugfs cleanup/fini code at amdgpu

Signed-off-by: Yintian Tao 


Reviewed-by: Christian König , but I would 
also give Alex an opportunity to take a look.



---
  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 30 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  1 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  1 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c|  7 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 ---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  1 -
  7 files changed, 51 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 3bb74056b9d2..abc148280ba5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -992,18 +992,6 @@ int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
return 0;
  }
  
-void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev)

-{
-   unsigned i;
-
-   for (i = 0; i < ARRAY_SIZE(debugfs_regs); i++) {
-   if (adev->debugfs_regs[i]) {
-   debugfs_remove(adev->debugfs_regs[i]);
-   adev->debugfs_regs[i] = NULL;
-   }
-   }
-}
-
  static int amdgpu_debugfs_test_ib(struct seq_file *m, void *data)
  {
struct drm_info_node *node = (struct drm_info_node *) m->private;
@@ -1339,31 +1327,13 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
ARRAY_SIZE(amdgpu_debugfs_list));
  }
  
-void amdgpu_debugfs_fini(struct amdgpu_device *adev)

-{
-   int i;
-
-   for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
-   struct amdgpu_ring *ring = adev->rings[i];
-
-   if (!ring)
-   continue;
-
-   amdgpu_debugfs_ring_fini(ring);
-   }
-   amdgpu_ttm_debugfs_fini(adev);
-   debugfs_remove(adev->debugfs_preempt);
-}
-
  #else
  int amdgpu_debugfs_init(struct amdgpu_device *adev)
  {
return 0;
  }
-void amdgpu_debugfs_fini(struct amdgpu_device *adev) { }
  int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
  {
return 0;
  }
-void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev) { }
  #endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h
index b382527e359a..de12d1101526 100644
--- 

RE: [PATCH] drm/amdgpu: miss to remove pp_sclk file

[Tao, Yintian]

Hi  Christian

Thanks a lot for your review


Hi  Alex


Can you help to review it? Thanks in advance.


Best Regards
Yintian Tao
-Original Message-
From: Koenig, Christian  
Sent: 2020年2月27日 22:18
To: Tao, Yintian ; Deucher, Alexander 

Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: miss to remove pp_sclk file

Am 27.02.20 um 15:11 schrieb Yintian Tao:
> Miss to remove pp_sclk file
>
> Signed-off-by: Yintian Tao 

Looks reasonable to me, but Alex can probably better judge.

Acked-by: Christian König 

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index 9deff8cc9723..a43fc1c8ffd0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -3471,6 +3471,7 @@ void amdgpu_pm_sysfs_fini(struct amdgpu_device *adev)
>   device_remove_file(adev->dev, _attr_pp_cur_state);
>   device_remove_file(adev->dev, _attr_pp_force_state);
>   device_remove_file(adev->dev, _attr_pp_table);
> + device_remove_file(adev->dev, _attr_pp_sclk);
>   
>   device_remove_file(adev->dev, _attr_pp_dpm_sclk);
>   device_remove_file(adev->dev, _attr_pp_dpm_mclk);

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

Re: [PATCH] drm/amdgpu: miss to remove pp_sclk file

[Christian König]

Am 27.02.20 um 15:11 schrieb Yintian Tao:

Miss to remove pp_sclk file

Signed-off-by: Yintian Tao 


Looks reasonable to me, but Alex can probably better judge.

Acked-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 9deff8cc9723..a43fc1c8ffd0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -3471,6 +3471,7 @@ void amdgpu_pm_sysfs_fini(struct amdgpu_device *adev)
device_remove_file(adev->dev, _attr_pp_cur_state);
device_remove_file(adev->dev, _attr_pp_force_state);
device_remove_file(adev->dev, _attr_pp_table);
+   device_remove_file(adev->dev, _attr_pp_sclk);
  
  	device_remove_file(adev->dev, _attr_pp_dpm_sclk);

device_remove_file(adev->dev, _attr_pp_dpm_mclk);


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

[PATCH] drm/amdgpu: miss to remove pp_sclk file

[Yintian Tao]

Miss to remove pp_sclk file

Signed-off-by: Yintian Tao 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 9deff8cc9723..a43fc1c8ffd0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -3471,6 +3471,7 @@ void amdgpu_pm_sysfs_fini(struct amdgpu_device *adev)
device_remove_file(adev->dev, _attr_pp_cur_state);
device_remove_file(adev->dev, _attr_pp_force_state);
device_remove_file(adev->dev, _attr_pp_table);
+   device_remove_file(adev->dev, _attr_pp_sclk);
 
device_remove_file(adev->dev, _attr_pp_dpm_sclk);
device_remove_file(adev->dev, _attr_pp_dpm_mclk);
-- 
2.17.1

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

Re: [PATCH] drm/amdgpu: Initialize SPM_VMID with 0xf

[Christian König]

Am 27.02.20 um 14:25 schrieb Jacob He:

SPM_VMID is a global resource, SPM access the video memory according to
SPM_VMID. The initial valude of SPM_VMID is 0 which is used by kernel.
That means UMD can overwrite the memory of VMID0 by enabling SPM, that
is really dangerous.

Initialize SPM_VMID with 0xf, it messes up other user mode process at
most.

Change-Id: Ieb54f6a16869b827504355a90a98663908d5087c
Signed-off-by: Jacob He 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h |  1 +
  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c  | 19 ++-
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   | 19 ++-
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   | 19 ++-
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   | 19 ++-
  5 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
index d3d4707f2168..52509c254cbd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
@@ -126,6 +126,7 @@ struct amdgpu_rlc_funcs {
void (*stop)(struct amdgpu_device *adev);
void (*reset)(struct amdgpu_device *adev);
void (*start)(struct amdgpu_device *adev);
+   void (*update_spm_vmid)(struct amdgpu_device *adev, unsigned vmid);
  };
  
  struct amdgpu_rlc {

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 7b6158320400..9fe5bdfa87ae 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -1016,6 +1016,10 @@ static int gfx_v10_0_rlc_init(struct amdgpu_device *adev)
return r;
}
  
+/* init spm vmid with 0xf */

+if (adev->gfx.rlc.funcs->update_spm_vmid)
+adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+
return 0;
  }
  
@@ -4214,6 +4218,18 @@ static int gfx_v10_0_update_gfx_clock_gating(struct amdgpu_device *adev,

return 0;
  }
  
+static void gfx_v10_0_update_spm_vmid(struct amdgpu_device *adev, unsigned vmid)

+{
+   u32 data;
+
+   data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
+
+   data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
+   data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) << 
RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
+
+   WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data);
+}
+
  static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs = {
.is_rlc_enabled = gfx_v10_0_is_rlc_enabled,
.set_safe_mode = gfx_v10_0_set_safe_mode,
@@ -4224,7 +4240,8 @@ static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs 
= {
.resume = gfx_v10_0_rlc_resume,
.stop = gfx_v10_0_rlc_stop,
.reset = gfx_v10_0_rlc_reset,
-   .start = gfx_v10_0_rlc_start
+   .start = gfx_v10_0_rlc_start,
+   .update_spm_vmid = gfx_v10_0_update_spm_vmid
  };
  
  static int gfx_v10_0_set_powergating_state(void *handle,

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 8f20a5dd44fe..80a959755cf3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -3346,6 +3346,10 @@ static int gfx_v7_0_rlc_init(struct amdgpu_device *adev)
return r;
}
  
+/* init spm vmid with 0xf */

+if (adev->gfx.rlc.funcs->update_spm_vmid)
+adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+
return 0;
  }
  
@@ -3570,6 +3574,18 @@ static int gfx_v7_0_rlc_resume(struct amdgpu_device *adev)

return 0;
  }
  
+static void gfx_v7_0_update_spm_vmid(struct amdgpu_device *adev, unsigned vmid)

+{
+   u32 data;
+
+   data = RREG32(mmRLC_SPM_VMID);
+
+   data &= ~RLC_SPM_VMID__RLC_SPM_VMID_MASK;
+   data |= (vmid & RLC_SPM_VMID__RLC_SPM_VMID_MASK) << 
RLC_SPM_VMID__RLC_SPM_VMID__SHIFT;
+
+   WREG32(mmRLC_SPM_VMID, data);
+}
+
  static void gfx_v7_0_enable_cgcg(struct amdgpu_device *adev, bool enable)
  {
u32 data, orig, tmp, tmp2;
@@ -4221,7 +4237,8 @@ static const struct amdgpu_rlc_funcs gfx_v7_0_rlc_funcs = 
{
.resume = gfx_v7_0_rlc_resume,
.stop = gfx_v7_0_rlc_stop,
.reset = gfx_v7_0_rlc_reset,
-   .start = gfx_v7_0_rlc_start
+   .start = gfx_v7_0_rlc_start,
+   .update_spm_vmid = gfx_v7_0_update_spm_vmid
  };
  
  static int gfx_v7_0_early_init(void *handle)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index fa245973de12..2174f9dc5335 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -1318,6 +1318,10 @@ static int gfx_v8_0_rlc_init(struct amdgpu_device *adev)
return r;
}
  
+/* init spm vmid with 0xf */

+if (adev->gfx.rlc.funcs->update_spm_vmid)
+adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+
return 0;
  }
  
@@ -5589,6 +5593,18 @@ static void gfx_v8_0_unset_safe_mode(struct amdgpu_device 

[PATCH] drm/amdgpu: Initialize SPM_VMID with 0xf

[Jacob He]

SPM_VMID is a global resource, SPM access the video memory according to
SPM_VMID. The initial valude of SPM_VMID is 0 which is used by kernel.
That means UMD can overwrite the memory of VMID0 by enabling SPM, that
is really dangerous.

Initialize SPM_VMID with 0xf, it messes up other user mode process at
most.

Change-Id: Ieb54f6a16869b827504355a90a98663908d5087c
Signed-off-by: Jacob He 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h |  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c  | 19 ++-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   | 19 ++-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   | 19 ++-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   | 19 ++-
 5 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
index d3d4707f2168..52509c254cbd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
@@ -126,6 +126,7 @@ struct amdgpu_rlc_funcs {
void (*stop)(struct amdgpu_device *adev);
void (*reset)(struct amdgpu_device *adev);
void (*start)(struct amdgpu_device *adev);
+   void (*update_spm_vmid)(struct amdgpu_device *adev, unsigned vmid);
 };
 
 struct amdgpu_rlc {
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 7b6158320400..9fe5bdfa87ae 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -1016,6 +1016,10 @@ static int gfx_v10_0_rlc_init(struct amdgpu_device *adev)
return r;
}
 
+/* init spm vmid with 0xf */
+if (adev->gfx.rlc.funcs->update_spm_vmid)
+adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+
return 0;
 }
 
@@ -4214,6 +4218,18 @@ static int gfx_v10_0_update_gfx_clock_gating(struct 
amdgpu_device *adev,
return 0;
 }
 
+static void gfx_v10_0_update_spm_vmid(struct amdgpu_device *adev, unsigned 
vmid)
+{
+   u32 data;
+
+   data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
+
+   data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
+   data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) << 
RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
+
+   WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data);
+}
+
 static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs = {
.is_rlc_enabled = gfx_v10_0_is_rlc_enabled,
.set_safe_mode = gfx_v10_0_set_safe_mode,
@@ -4224,7 +4240,8 @@ static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs 
= {
.resume = gfx_v10_0_rlc_resume,
.stop = gfx_v10_0_rlc_stop,
.reset = gfx_v10_0_rlc_reset,
-   .start = gfx_v10_0_rlc_start
+   .start = gfx_v10_0_rlc_start,
+   .update_spm_vmid = gfx_v10_0_update_spm_vmid
 };
 
 static int gfx_v10_0_set_powergating_state(void *handle,
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 8f20a5dd44fe..80a959755cf3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -3346,6 +3346,10 @@ static int gfx_v7_0_rlc_init(struct amdgpu_device *adev)
return r;
}
 
+/* init spm vmid with 0xf */
+if (adev->gfx.rlc.funcs->update_spm_vmid)
+adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+
return 0;
 }
 
@@ -3570,6 +3574,18 @@ static int gfx_v7_0_rlc_resume(struct amdgpu_device 
*adev)
return 0;
 }
 
+static void gfx_v7_0_update_spm_vmid(struct amdgpu_device *adev, unsigned vmid)
+{
+   u32 data;
+
+   data = RREG32(mmRLC_SPM_VMID);
+
+   data &= ~RLC_SPM_VMID__RLC_SPM_VMID_MASK;
+   data |= (vmid & RLC_SPM_VMID__RLC_SPM_VMID_MASK) << 
RLC_SPM_VMID__RLC_SPM_VMID__SHIFT;
+
+   WREG32(mmRLC_SPM_VMID, data);
+}
+
 static void gfx_v7_0_enable_cgcg(struct amdgpu_device *adev, bool enable)
 {
u32 data, orig, tmp, tmp2;
@@ -4221,7 +4237,8 @@ static const struct amdgpu_rlc_funcs gfx_v7_0_rlc_funcs = 
{
.resume = gfx_v7_0_rlc_resume,
.stop = gfx_v7_0_rlc_stop,
.reset = gfx_v7_0_rlc_reset,
-   .start = gfx_v7_0_rlc_start
+   .start = gfx_v7_0_rlc_start,
+   .update_spm_vmid = gfx_v7_0_update_spm_vmid
 };
 
 static int gfx_v7_0_early_init(void *handle)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index fa245973de12..2174f9dc5335 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -1318,6 +1318,10 @@ static int gfx_v8_0_rlc_init(struct amdgpu_device *adev)
return r;
}
 
+/* init spm vmid with 0xf */
+if (adev->gfx.rlc.funcs->update_spm_vmid)
+adev->gfx.rlc.funcs->update_spm_vmid(adev, 0xf);
+
return 0;
 }
 
@@ -5589,6 +5593,18 @@ static void gfx_v8_0_unset_safe_mode(struct 
amdgpu_device *adev)
}
 }
 
+static void gfx_v8_0_update_spm_vmid(struct amdgpu_device *adev, unsigned vmid)
+{
+   

[PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

[Yintian Tao]

drm_minor_unregister will invoke drm_debugfs_cleanup
to clean all the child node under primary minor node.
We don't need to invoke amdgpu_debugfs_fini and
amdgpu_debugfs_regs_cleanup to clean agian.
Otherwise, it will raise the NULL pointer like below.
[   45.046029] BUG: unable to handle kernel NULL pointer dereference at 
00a8
[   45.047256] PGD 0 P4D 0
[   45.047713] Oops: 0002 [#1] SMP PTI
[   45.048198] CPU: 0 PID: 2796 Comm: modprobe Tainted: GW  OE 
4.18.0-15-generic #16~18.04.1-Ubuntu
[   45.049538] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   45.050651] RIP: 0010:down_write+0x1f/0x40
[   45.051194] Code: 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 
e5 53 48 89 fb e8 ce d9 ff ff 48 ba 01 00 00 00 ff ff ff ff 48 89 d8  48 0f 
c1 10 85 d2 74 05 e8 53 1c ff ff 65 48 8b 04 25 00 5c 01
[   45.053702] RSP: 0018:ad8f4133fd40 EFLAGS: 00010246
[   45.054384] RAX: 00a8 RBX: 00a8 RCX: a011327dd814
[   45.055349] RDX: 0001 RSI: 0001 RDI: 00a8
[   45.056346] RBP: ad8f4133fd48 R08:  R09: c0690a00
[   45.057326] R10: ad8f4133fd58 R11: 0001 R12: a0113cff0300
[   45.058266] R13: a0113c0a R14: c0c02a10 R15: a0113e5c7860
[   45.059221] FS:  7f60d46f9540() GS:a0113fc0() 
knlGS:
[   45.060809] CS:  0010 DS:  ES:  CR0: 80050033
[   45.061826] CR2: 00a8 CR3: 000136250004 CR4: 003606f0
[   45.062913] DR0:  DR1:  DR2: 
[   45.064404] DR3:  DR6: fffe0ff0 DR7: 0400
[   45.065897] Call Trace:
[   45.066426]  debugfs_remove+0x36/0xa0
[   45.067131]  amdgpu_debugfs_ring_fini+0x15/0x20 [amdgpu]
[   45.068019]  amdgpu_debugfs_fini+0x2c/0x50 [amdgpu]
[   45.068756]  amdgpu_pci_remove+0x49/0x70 [amdgpu]
[   45.069439]  pci_device_remove+0x3e/0xc0
[   45.070037]  device_release_driver_internal+0x18a/0x260
[   45.070842]  driver_detach+0x3f/0x80
[   45.071325]  bus_remove_driver+0x59/0xd0
[   45.071850]  driver_unregister+0x2c/0x40
[   45.072377]  pci_unregister_driver+0x22/0xa0
[   45.073043]  amdgpu_exit+0x15/0x57c [amdgpu]
[   45.073683]  __x64_sys_delete_module+0x146/0x280
[   45.074369]  do_syscall_64+0x5a/0x120
[   45.074916]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

v2: remove all debugfs cleanup/fini code at amdgpu

Signed-off-by: Yintian Tao 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 30 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c|  7 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  1 -
 7 files changed, 51 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 3bb74056b9d2..abc148280ba5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -992,18 +992,6 @@ int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
return 0;
 }
 
-void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev)
-{
-   unsigned i;
-
-   for (i = 0; i < ARRAY_SIZE(debugfs_regs); i++) {
-   if (adev->debugfs_regs[i]) {
-   debugfs_remove(adev->debugfs_regs[i]);
-   adev->debugfs_regs[i] = NULL;
-   }
-   }
-}
-
 static int amdgpu_debugfs_test_ib(struct seq_file *m, void *data)
 {
struct drm_info_node *node = (struct drm_info_node *) m->private;
@@ -1339,31 +1327,13 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
ARRAY_SIZE(amdgpu_debugfs_list));
 }
 
-void amdgpu_debugfs_fini(struct amdgpu_device *adev)
-{
-   int i;
-
-   for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
-   struct amdgpu_ring *ring = adev->rings[i];
-
-   if (!ring)
-   continue;
-
-   amdgpu_debugfs_ring_fini(ring);
-   }
-   amdgpu_ttm_debugfs_fini(adev);
-   debugfs_remove(adev->debugfs_preempt);
-}
-
 #else
 int amdgpu_debugfs_init(struct amdgpu_device *adev)
 {
return 0;
 }
-void amdgpu_debugfs_fini(struct amdgpu_device *adev) { }
 int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
 {
return 0;
 }
-void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev) { }
 #endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h
index b382527e359a..de12d1101526 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h
@@ -32,7 +32,6 @@ struct amdgpu_debugfs {
 };
 
 int amdgpu_debugfs_regs_init(struct amdgpu_device *adev);

Re: [PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

[Huang Rui]

On Thu, Feb 27, 2020 at 07:47:17PM +0800, Koenig, Christian wrote:
> Am 27.02.20 um 12:38 schrieb Huang Rui:
> > Since 6643ba1 frame control packets are only issued in presence of secure 
> > IB(s).
> > This causes hangs on some hardware (eg: Raven1). This patch restores the
> > unconditionnal frame control packets issuing, that's to keep the per-IB 
> > logic
> > regarding the secure flag.
> >
> > Fixes: 6643ba1 drm/amdgpu: Move to a per-IB secure flag (TMZ)
> >
> > v1 -> v2:
> > As suggested by Luben, and accept part of implemetation from this patch:
> > - Put "secure" closed to the loop and use optimization
> > - Change "secure" to bool again, and move "secure == -1" out of loop.
> >
> > Reported-and-Tested-by: Pierre-Eric Pelloux-Prayer 
> > 
> > Signed-off-by: Huang Rui 
> > Reviewed-by: Alex Deucher 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   | 29 
> > +++--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  5 +++--
> >   drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 15 ---
> >   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 +++--
> >   4 files changed, 33 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> > index 4b2342d..0f4909a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> > @@ -216,7 +216,14 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, 
> > unsigned num_ibs,
> > amdgpu_ring_emit_cntxcntl(ring, status);
> > }
> >   
> > +   /* Setup initial TMZiness and send it off.
> > +*/
> > secure = false;
> > +   if (job && ring->funcs->emit_frame_cntl) {
> 
> Does anybody remember why we check the job here in the first place?

Align with previous logic, we only issue this packet while it's user mode
submission. Looks ib tests needn't this.

> 
> Independent of that I think that the check if 
> ring->funcs->emit_frame_cntl should be moved into the 
> amdgpu_ring_emit_frame_cntl() function so that we don't need to repeat 
> that over and over again.
> 
> If amdgpu_ring_emit_frame_cntl() is still a macro then that is probably 
> also a good opportunity to change that.

Agree, this looks better.

> 
> > +   secure = ib->flags & AMDGPU_IB_FLAGS_SECURE ? true : false;
> > +   amdgpu_ring_emit_frame_cntl(ring, true, secure);
> > +   }
> > +
> > for (i = 0; i < num_ibs; ++i) {
> > ib = [i];
> >   
> > @@ -228,27 +235,21 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, 
> > unsigned num_ibs,
> > !amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble 
> > CE ib must be inserted anyway */
> > continue;
> >   
> > -   /* If this IB is TMZ, add frame TMZ start packet,
> > -* else, turn off TMZ.
> > -*/
> > -   if (ib->flags & AMDGPU_IB_FLAGS_SECURE && 
> > ring->funcs->emit_tmz) {
> > -   if (!secure) {
> > -   secure = true;
> > -   amdgpu_ring_emit_tmz(ring, true);
> > +   if (job && ring->funcs->emit_frame_cntl) {
> > +   if (!!secure ^ !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)) {
> 
> Maybe write this as (secure != !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)). 
> That is probably easier to understand.

Actually, I spend quit a few minutes to understand previous checking. :-)
I am fine to change if Lunben has no objection.

Thanks,
Ray

> 
> Regards,
> Christian.
> 
> > +   amdgpu_ring_emit_frame_cntl(ring, false, 
> > secure);
> > +   secure = !secure;
> > +   amdgpu_ring_emit_frame_cntl(ring, true, secure);
> > }
> > -   } else if (secure) {
> > -   secure = false;
> > -   amdgpu_ring_emit_tmz(ring, false);
> > }
> >   
> > amdgpu_ring_emit_ib(ring, job, ib, status);
> > status &= ~AMDGPU_HAVE_CTX_SWITCH;
> > }
> >   
> > -   if (secure) {
> > -   secure = false;
> > -   amdgpu_ring_emit_tmz(ring, false);
> > -   }
> > +   if (job && ring->funcs->emit_frame_cntl)
> > +   amdgpu_ring_emit_frame_cntl(ring, false,
> > +   secure ? true : false);
> >   
> >   #ifdef CONFIG_X86_64
> > if (!(adev->flags & AMD_IS_APU))
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> > index 24caff0..4d019d6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> > @@ -166,7 +166,8 @@ struct amdgpu_ring_funcs {
> > void (*emit_reg_write_reg_wait)(struct amdgpu_ring *ring,
> > uint32_t reg0, uint32_t reg1,
> > uint32_t ref, uint32_t mask);
> > -   void (*emit_tmz)(struct amdgpu_ring *ring, bool start);
> 

RE: [PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

[Tao, Yintian]

Hi  Christian

Thanks for your suggestion. I will remove all cleanup/fini code as well.

Best Regards
Yintian Tao

-Original Message-
From: Koenig, Christian  
Sent: 2020年2月27日 19:54
To: Tao, Yintian ; Deucher, Alexander 

Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

If we do this we should probably make nails with heads and remove the whole 
cleanup/fini code as well.

Christian.

Am 27.02.20 um 12:50 schrieb Yintian Tao:
> drm_minor_unregister will invoke drm_debugfs_cleanup to clean all the 
> child node under primary minor node.
> We don't need to invoke amdgpu_debugfs_fini and 
> amdgpu_debugfs_regs_cleanup to clean agian.
> Otherwise, it will raise the NULL pointer like below.
> [   45.046029] BUG: unable to handle kernel NULL pointer dereference at 
> 00a8
> [   45.047256] PGD 0 P4D 0
> [   45.047713] Oops: 0002 [#1] SMP PTI
> [   45.048198] CPU: 0 PID: 2796 Comm: modprobe Tainted: GW  OE 
> 4.18.0-15-generic #16~18.04.1-Ubuntu
> [   45.049538] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.12.0-1 04/01/2014
> [   45.050651] RIP: 0010:down_write+0x1f/0x40
> [   45.051194] Code: 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 
> e5 53 48 89 fb e8 ce d9 ff ff 48 ba 01 00 00 00 ff ff ff ff 48 89 d8  48 
> 0f c1 10 85 d2 74 05 e8 53 1c ff ff 65 48 8b 04 25 00 5c 01
> [   45.053702] RSP: 0018:ad8f4133fd40 EFLAGS: 00010246
> [   45.054384] RAX: 00a8 RBX: 00a8 RCX: 
> a011327dd814
> [   45.055349] RDX: 0001 RSI: 0001 RDI: 
> 00a8
> [   45.056346] RBP: ad8f4133fd48 R08:  R09: 
> c0690a00
> [   45.057326] R10: ad8f4133fd58 R11: 0001 R12: 
> a0113cff0300
> [   45.058266] R13: a0113c0a R14: c0c02a10 R15: 
> a0113e5c7860
> [   45.059221] FS:  7f60d46f9540() GS:a0113fc0() 
> knlGS:
> [   45.060809] CS:  0010 DS:  ES:  CR0: 80050033
> [   45.061826] CR2: 00a8 CR3: 000136250004 CR4: 
> 003606f0
> [   45.062913] DR0:  DR1:  DR2: 
> 
> [   45.064404] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   45.065897] Call Trace:
> [   45.066426]  debugfs_remove+0x36/0xa0
> [   45.067131]  amdgpu_debugfs_ring_fini+0x15/0x20 [amdgpu]
> [   45.068019]  amdgpu_debugfs_fini+0x2c/0x50 [amdgpu]
> [   45.068756]  amdgpu_pci_remove+0x49/0x70 [amdgpu]
> [   45.069439]  pci_device_remove+0x3e/0xc0
> [   45.070037]  device_release_driver_internal+0x18a/0x260
> [   45.070842]  driver_detach+0x3f/0x80
> [   45.071325]  bus_remove_driver+0x59/0xd0
> [   45.071850]  driver_unregister+0x2c/0x40
> [   45.072377]  pci_unregister_driver+0x22/0xa0
> [   45.073043]  amdgpu_exit+0x15/0x57c [amdgpu]
> [   45.073683]  __x64_sys_delete_module+0x146/0x280
> [   45.074369]  do_syscall_64+0x5a/0x120
> [   45.074916]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Signed-off-by: Yintian Tao 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 -
>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 -
>   2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 8ef8a49b9255..351096ab4301 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3237,7 +3237,6 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
>   adev->rmmio = NULL;
>   amdgpu_device_doorbell_fini(adev);
>   
> - amdgpu_debugfs_regs_cleanup(adev);
>   device_remove_file(adev->dev, _attr_pcie_replay_count);
>   if (adev->ucode_sysfs_en)
>   amdgpu_ucode_sysfs_fini(adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 7cf5f597b90a..02d80b9dbfe1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1139,7 +1139,6 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>   DRM_ERROR("Hotplug removal is not supported\n");
>   drm_dev_unplug(dev);
>   drm_dev_put(dev);
> - amdgpu_debugfs_fini(adev);
>   amdgpu_driver_unload_kms(dev);
>   pci_disable_device(pdev);
>   pci_set_drvdata(pdev, NULL);

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

[PATCH] drm/amdgpu: release drm_device after amdgpu_driver_unload_kms

[Yintian Tao]

If we release drm_device before amdgpu_driver_unload_kms,
then it will raise the error below. Therefore, we need to
place it before amdgpu_driver_unload_kms.
[   43.055736] Memory manager not clean during takedown.
[   43.055777] WARNING: CPU: 1 PID: 2807 at 
/build/linux-hwe-9KJ07q/linux-hwe-4.18.0/drivers/gpu/drm/drm_mm.c:913 
drm_mm_takedown+0x24/0x30 [drm]
[   43.055778] Modules linked in: amdgpu(OE-) amd_sched(OE) amdttm(OE) 
amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea 
sysfillrect sysimgblt snd_hda_codec_generic nfit kvm_intel kvm irqbypass 
crct10dif_pclmul crc32_pclmul snd_hda_intel snd_hda_codec snd_hda_core 
snd_hwdep snd_pcm ghash_clmulni_intel snd_seq_midi snd_seq_midi_event pcbc 
snd_rawmidi snd_seq snd_seq_device aesni_intel snd_timer joydev aes_x86_64 
crypto_simd cryptd glue_helper snd soundcore input_leds mac_hid serio_raw 
qemu_fw_cfg binfmt_misc sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace 
sunrpc parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic 
floppy usbhid psmouse hid i2c_piix4 e1000 pata_acpi
[   43.055819] CPU: 1 PID: 2807 Comm: modprobe Tainted: G   OE 
4.18.0-15-generic #16~18.04.1-Ubuntu
[   43.055820] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   43.055830] RIP: 0010:drm_mm_takedown+0x24/0x30 [drm]
[   43.055831] Code: 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 38 48 83 c7 38 
48 39 c7 75 02 f3 c3 55 48 c7 c7 38 33 80 c0 48 89 e5 e8 1c 41 ec d0 <0f> 0b 5d 
c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
[   43.055857] RSP: 0018:ae33c1393d28 EFLAGS: 00010286
[   43.055859] RAX:  RBX: 9651b4a29800 RCX: 0006
[   43.055860] RDX: 0007 RSI: 0096 RDI: 9651bfc964b0
[   43.055861] RBP: ae33c1393d28 R08: 02a6 R09: 0004
[   43.055861] R10: ae33c1393d20 R11: 0001 R12: 9651ba6cb000
[   43.055863] R13: 9651b7f4 R14: c0de3a10 R15: 9651ba5c6460
[   43.055864] FS:  7f1d3c08d540() GS:9651bfc8() 
knlGS:
[   43.055865] CS:  0010 DS:  ES:  CR0: 80050033
[   43.055866] CR2: 5630a5831640 CR3: 00012e274004 CR4: 003606e0
[   43.055870] DR0:  DR1:  DR2: 
[   43.055871] DR3:  DR6: fffe0ff0 DR7: 0400
[   43.055871] Call Trace:
[   43.055885]  drm_vma_offset_manager_destroy+0x1b/0x30 [drm]
[   43.055894]  drm_gem_destroy+0x19/0x40 [drm]
[   43.055903]  drm_dev_fini+0x7f/0x90 [drm]
[   43.055911]  drm_dev_release+0x2b/0x40 [drm]
[   43.055919]  drm_dev_unplug+0x64/0x80 [drm]
[   43.055994]  amdgpu_pci_remove+0x39/0x70 [amdgpu]
[   43.055998]  pci_device_remove+0x3e/0xc0
[   43.056001]  device_release_driver_internal+0x18a/0x260
[   43.056003]  driver_detach+0x3f/0x80
[   43.056004]  bus_remove_driver+0x59/0xd0
[   43.056006]  driver_unregister+0x2c/0x40
[   43.056008]  pci_unregister_driver+0x22/0xa0
[   43.056087]  amdgpu_exit+0x15/0x57c [amdgpu]
[   43.056090]  __x64_sys_delete_module+0x146/0x280
[   43.056094]  do_syscall_64+0x5a/0x120

Signed-off-by: Yintian Tao 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 02d80b9dbfe1..01a1082b5cab 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1138,8 +1138,8 @@ amdgpu_pci_remove(struct pci_dev *pdev)
 #endif
DRM_ERROR("Hotplug removal is not supported\n");
drm_dev_unplug(dev);
-   drm_dev_put(dev);
amdgpu_driver_unload_kms(dev);
+   drm_dev_put(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
 }
-- 
2.17.1

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

Re: [PATCH 1/1] drm/amdgpu: Fix per-IB secure flag GFX hang

[Huang Rui]

On Thu, Feb 27, 2020 at 06:39:03AM +0800, Tuikov, Luben wrote:
> Since commit "Move to a per-IB secure flag (TMZ)",
> we've been seeing hangs in GFX. Ray H. pointed out
> by sending a patch that we need to send FRAME
> CONTROL stop/start back-to-back, every time we
> flip the TMZ flag as per each IB we submit. That
> is, when we transition from TMZ to non-TMZ we have
> to send a stop with TMZ followed by a start with
> non-TMZ, and similarly for transitioning from
> non-TMZ into TMZ.
> 
> This patch implements this, thus fixing the GFX
> hang.
> 
> Signed-off-by: Luben Tuikov 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   | 87 +---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  5 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 15 ++--
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 ++--
>  4 files changed, 79 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> index 4b2342d11520..16d6df3304d3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> @@ -216,40 +216,75 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, 
> unsigned num_ibs,
>   amdgpu_ring_emit_cntxcntl(ring, status);
>   }
>  
> - secure = false;
> + /* Find the first non-preamble IB.
> +  */
>   for (i = 0; i < num_ibs; ++i) {
>   ib = [i];
>  
>   /* drop preamble IBs if we don't have a context switch */
> - if ((ib->flags & AMDGPU_IB_FLAG_PREAMBLE) &&
> - skip_preamble &&
> - !(status & AMDGPU_PREAMBLE_IB_PRESENT_FIRST) &&
> - !amdgpu_mcbp &&
> - !amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble 
> CE ib must be inserted anyway */
> - continue;
> -
> - /* If this IB is TMZ, add frame TMZ start packet,
> -  * else, turn off TMZ.
> -  */
> - if (ib->flags & AMDGPU_IB_FLAGS_SECURE && 
> ring->funcs->emit_tmz) {
> - if (!secure) {
> - secure = true;
> - amdgpu_ring_emit_tmz(ring, true);
> - }
> - } else if (secure) {
> + if (!(ib->flags & AMDGPU_IB_FLAG_PREAMBLE) ||
> + !skip_preamble ||
> + (status & AMDGPU_PREAMBLE_IB_PRESENT_FIRST) ||
> + amdgpu_mcbp ||
> + amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble CE 
> ib must be inserted anyway */
> + break;
> + }
> + if (i >= num_ibs)
> + goto Done;
> + /* Setup initial TMZiness and send it off.
> +  */
> + secure = false;
> + if (job && ring->funcs->emit_frame_cntl) {
> + if (ib->flags & AMDGPU_IB_FLAGS_SECURE)
> + secure = true;
> + else
>   secure = false;
> - amdgpu_ring_emit_tmz(ring, false);
> - }
> -
> - amdgpu_ring_emit_ib(ring, job, ib, status);
> - status &= ~AMDGPU_HAVE_CTX_SWITCH;
> + amdgpu_ring_emit_frame_cntl(ring, true, secure);
>   }
> + amdgpu_ring_emit_ib(ring, job, ib, status);
> + status &= ~AMDGPU_HAVE_CTX_SWITCH;
> + i += 1;
> + /* Send the rest of the IBs.
> +  */
> + if (job && ring->funcs->emit_frame_cntl) {
> + for ( ; i < num_ibs; ++i) {
> + ib = [i];
> +
> + /* drop preamble IBs if we don't have a context switch 
> */
> + if ((ib->flags & AMDGPU_IB_FLAG_PREAMBLE) &&
> + skip_preamble &&
> + !(status & AMDGPU_PREAMBLE_IB_PRESENT_FIRST) &&
> + !amdgpu_mcbp &&
> + !amdgpu_sriov_vf(adev)) /* for SRIOV preemption, 
> Preamble CE ib must be inserted anyway */
> + continue;

Snip.

> +
> + if (!!secure ^ !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)) {
> + amdgpu_ring_emit_frame_cntl(ring, false, 
> secure);
> + secure = !secure;
> + amdgpu_ring_emit_frame_cntl(ring, true, secure);
> + }

That's pretty good optimization! I spend quit a few time to understand this.

>  
> - if (secure) {
> - secure = false;
> - amdgpu_ring_emit_tmz(ring, false);
> + amdgpu_ring_emit_ib(ring, job, ib, status);
> + status &= ~AMDGPU_HAVE_CTX_SWITCH;
> + }
> + amdgpu_ring_emit_frame_cntl(ring, false, secure);
> + } else {
> + for ( ; i < num_ibs; ++i) {
> + ib = [i];
> +
> + /* drop preamble IBs if we don't have a context switch 
> */
> + if ((ib->flags & 

Re: [PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

[Christian König]

If we do this we should probably make nails with heads and remove the 
whole cleanup/fini code as well.


Christian.

Am 27.02.20 um 12:50 schrieb Yintian Tao:

drm_minor_unregister will invoke drm_debugfs_cleanup
to clean all the child node under primary minor node.
We don't need to invoke amdgpu_debugfs_fini and
amdgpu_debugfs_regs_cleanup to clean agian.
Otherwise, it will raise the NULL pointer like below.
[   45.046029] BUG: unable to handle kernel NULL pointer dereference at 
00a8
[   45.047256] PGD 0 P4D 0
[   45.047713] Oops: 0002 [#1] SMP PTI
[   45.048198] CPU: 0 PID: 2796 Comm: modprobe Tainted: GW  OE 
4.18.0-15-generic #16~18.04.1-Ubuntu
[   45.049538] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   45.050651] RIP: 0010:down_write+0x1f/0x40
[   45.051194] Code: 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 
48 89 fb e8 ce d9 ff ff 48 ba 01 00 00 00 ff ff ff ff 48 89 d8  48 0f c1 10 
85 d2 74 05 e8 53 1c ff ff 65 48 8b 04 25 00 5c 01
[   45.053702] RSP: 0018:ad8f4133fd40 EFLAGS: 00010246
[   45.054384] RAX: 00a8 RBX: 00a8 RCX: a011327dd814
[   45.055349] RDX: 0001 RSI: 0001 RDI: 00a8
[   45.056346] RBP: ad8f4133fd48 R08:  R09: c0690a00
[   45.057326] R10: ad8f4133fd58 R11: 0001 R12: a0113cff0300
[   45.058266] R13: a0113c0a R14: c0c02a10 R15: a0113e5c7860
[   45.059221] FS:  7f60d46f9540() GS:a0113fc0() 
knlGS:
[   45.060809] CS:  0010 DS:  ES:  CR0: 80050033
[   45.061826] CR2: 00a8 CR3: 000136250004 CR4: 003606f0
[   45.062913] DR0:  DR1:  DR2: 
[   45.064404] DR3:  DR6: fffe0ff0 DR7: 0400
[   45.065897] Call Trace:
[   45.066426]  debugfs_remove+0x36/0xa0
[   45.067131]  amdgpu_debugfs_ring_fini+0x15/0x20 [amdgpu]
[   45.068019]  amdgpu_debugfs_fini+0x2c/0x50 [amdgpu]
[   45.068756]  amdgpu_pci_remove+0x49/0x70 [amdgpu]
[   45.069439]  pci_device_remove+0x3e/0xc0
[   45.070037]  device_release_driver_internal+0x18a/0x260
[   45.070842]  driver_detach+0x3f/0x80
[   45.071325]  bus_remove_driver+0x59/0xd0
[   45.071850]  driver_unregister+0x2c/0x40
[   45.072377]  pci_unregister_driver+0x22/0xa0
[   45.073043]  amdgpu_exit+0x15/0x57c [amdgpu]
[   45.073683]  __x64_sys_delete_module+0x146/0x280
[   45.074369]  do_syscall_64+0x5a/0x120
[   45.074916]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Yintian Tao 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 -
  2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8ef8a49b9255..351096ab4301 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3237,7 +3237,6 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
adev->rmmio = NULL;
amdgpu_device_doorbell_fini(adev);
  
-	amdgpu_debugfs_regs_cleanup(adev);

device_remove_file(adev->dev, _attr_pcie_replay_count);
if (adev->ucode_sysfs_en)
amdgpu_ucode_sysfs_fini(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 7cf5f597b90a..02d80b9dbfe1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1139,7 +1139,6 @@ amdgpu_pci_remove(struct pci_dev *pdev)
DRM_ERROR("Hotplug removal is not supported\n");
drm_dev_unplug(dev);
drm_dev_put(dev);
-   amdgpu_debugfs_fini(adev);
amdgpu_driver_unload_kms(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);


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

[PATCH] drm/amdgpu: no need to clean debugfs at amdgpu

[Yintian Tao]

drm_minor_unregister will invoke drm_debugfs_cleanup
to clean all the child node under primary minor node.
We don't need to invoke amdgpu_debugfs_fini and
amdgpu_debugfs_regs_cleanup to clean agian.
Otherwise, it will raise the NULL pointer like below.
[   45.046029] BUG: unable to handle kernel NULL pointer dereference at 
00a8
[   45.047256] PGD 0 P4D 0
[   45.047713] Oops: 0002 [#1] SMP PTI
[   45.048198] CPU: 0 PID: 2796 Comm: modprobe Tainted: GW  OE 
4.18.0-15-generic #16~18.04.1-Ubuntu
[   45.049538] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   45.050651] RIP: 0010:down_write+0x1f/0x40
[   45.051194] Code: 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 
e5 53 48 89 fb e8 ce d9 ff ff 48 ba 01 00 00 00 ff ff ff ff 48 89 d8  48 0f 
c1 10 85 d2 74 05 e8 53 1c ff ff 65 48 8b 04 25 00 5c 01
[   45.053702] RSP: 0018:ad8f4133fd40 EFLAGS: 00010246
[   45.054384] RAX: 00a8 RBX: 00a8 RCX: a011327dd814
[   45.055349] RDX: 0001 RSI: 0001 RDI: 00a8
[   45.056346] RBP: ad8f4133fd48 R08:  R09: c0690a00
[   45.057326] R10: ad8f4133fd58 R11: 0001 R12: a0113cff0300
[   45.058266] R13: a0113c0a R14: c0c02a10 R15: a0113e5c7860
[   45.059221] FS:  7f60d46f9540() GS:a0113fc0() 
knlGS:
[   45.060809] CS:  0010 DS:  ES:  CR0: 80050033
[   45.061826] CR2: 00a8 CR3: 000136250004 CR4: 003606f0
[   45.062913] DR0:  DR1:  DR2: 
[   45.064404] DR3:  DR6: fffe0ff0 DR7: 0400
[   45.065897] Call Trace:
[   45.066426]  debugfs_remove+0x36/0xa0
[   45.067131]  amdgpu_debugfs_ring_fini+0x15/0x20 [amdgpu]
[   45.068019]  amdgpu_debugfs_fini+0x2c/0x50 [amdgpu]
[   45.068756]  amdgpu_pci_remove+0x49/0x70 [amdgpu]
[   45.069439]  pci_device_remove+0x3e/0xc0
[   45.070037]  device_release_driver_internal+0x18a/0x260
[   45.070842]  driver_detach+0x3f/0x80
[   45.071325]  bus_remove_driver+0x59/0xd0
[   45.071850]  driver_unregister+0x2c/0x40
[   45.072377]  pci_unregister_driver+0x22/0xa0
[   45.073043]  amdgpu_exit+0x15/0x57c [amdgpu]
[   45.073683]  __x64_sys_delete_module+0x146/0x280
[   45.074369]  do_syscall_64+0x5a/0x120
[   45.074916]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Yintian Tao 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8ef8a49b9255..351096ab4301 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3237,7 +3237,6 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
adev->rmmio = NULL;
amdgpu_device_doorbell_fini(adev);
 
-   amdgpu_debugfs_regs_cleanup(adev);
device_remove_file(adev->dev, _attr_pcie_replay_count);
if (adev->ucode_sysfs_en)
amdgpu_ucode_sysfs_fini(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 7cf5f597b90a..02d80b9dbfe1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1139,7 +1139,6 @@ amdgpu_pci_remove(struct pci_dev *pdev)
DRM_ERROR("Hotplug removal is not supported\n");
drm_dev_unplug(dev);
drm_dev_put(dev);
-   amdgpu_debugfs_fini(adev);
amdgpu_driver_unload_kms(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
-- 
2.17.1

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

Re: [PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

[Christian König]

Am 27.02.20 um 12:38 schrieb Huang Rui:

Since 6643ba1 frame control packets are only issued in presence of secure IB(s).
This causes hangs on some hardware (eg: Raven1). This patch restores the
unconditionnal frame control packets issuing, that's to keep the per-IB logic
regarding the secure flag.

Fixes: 6643ba1 drm/amdgpu: Move to a per-IB secure flag (TMZ)

v1 -> v2:
As suggested by Luben, and accept part of implemetation from this patch:
- Put "secure" closed to the loop and use optimization
- Change "secure" to bool again, and move "secure == -1" out of loop.

Reported-and-Tested-by: Pierre-Eric Pelloux-Prayer 

Signed-off-by: Huang Rui 
Reviewed-by: Alex Deucher 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   | 29 +++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  5 +++--
  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 15 ---
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 +++--
  4 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 4b2342d..0f4909a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -216,7 +216,14 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
amdgpu_ring_emit_cntxcntl(ring, status);
}
  
+	/* Setup initial TMZiness and send it off.

+*/
secure = false;
+   if (job && ring->funcs->emit_frame_cntl) {


Does anybody remember why we check the job here in the first place?

Independent of that I think that the check if 
ring->funcs->emit_frame_cntl should be moved into the 
amdgpu_ring_emit_frame_cntl() function so that we don't need to repeat 
that over and over again.


If amdgpu_ring_emit_frame_cntl() is still a macro then that is probably 
also a good opportunity to change that.



+   secure = ib->flags & AMDGPU_IB_FLAGS_SECURE ? true : false;
+   amdgpu_ring_emit_frame_cntl(ring, true, secure);
+   }
+
for (i = 0; i < num_ibs; ++i) {
ib = [i];
  
@@ -228,27 +235,21 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs,

!amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble 
CE ib must be inserted anyway */
continue;
  
-		/* If this IB is TMZ, add frame TMZ start packet,

-* else, turn off TMZ.
-*/
-   if (ib->flags & AMDGPU_IB_FLAGS_SECURE && 
ring->funcs->emit_tmz) {
-   if (!secure) {
-   secure = true;
-   amdgpu_ring_emit_tmz(ring, true);
+   if (job && ring->funcs->emit_frame_cntl) {
+   if (!!secure ^ !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)) {


Maybe write this as (secure != !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)). 
That is probably easier to understand.


Regards,
Christian.


+   amdgpu_ring_emit_frame_cntl(ring, false, 
secure);
+   secure = !secure;
+   amdgpu_ring_emit_frame_cntl(ring, true, secure);
}
-   } else if (secure) {
-   secure = false;
-   amdgpu_ring_emit_tmz(ring, false);
}
  
  		amdgpu_ring_emit_ib(ring, job, ib, status);

status &= ~AMDGPU_HAVE_CTX_SWITCH;
}
  
-	if (secure) {

-   secure = false;
-   amdgpu_ring_emit_tmz(ring, false);
-   }
+   if (job && ring->funcs->emit_frame_cntl)
+   amdgpu_ring_emit_frame_cntl(ring, false,
+   secure ? true : false);
  
  #ifdef CONFIG_X86_64

if (!(adev->flags & AMD_IS_APU))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 24caff0..4d019d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -166,7 +166,8 @@ struct amdgpu_ring_funcs {
void (*emit_reg_write_reg_wait)(struct amdgpu_ring *ring,
uint32_t reg0, uint32_t reg1,
uint32_t ref, uint32_t mask);
-   void (*emit_tmz)(struct amdgpu_ring *ring, bool start);
+   void (*emit_frame_cntl)(struct amdgpu_ring *ring, bool start,
+   bool secure);
/* priority functions */
void (*set_priority) (struct amdgpu_ring *ring,
  enum drm_sched_priority priority);
@@ -247,7 +248,7 @@ struct amdgpu_ring {
  #define amdgpu_ring_emit_wreg(r, d, v) (r)->funcs->emit_wreg((r), (d), (v))
  #define amdgpu_ring_emit_reg_wait(r, d, v, m) (r)->funcs->emit_reg_wait((r), 
(d), (v), (m))
  #define amdgpu_ring_emit_reg_write_reg_wait(r, d0, d1, v, m) 
(r)->funcs->emit_reg_write_reg_wait((r), (d0), (d1), (v), (m))

[PATCH v2] drm/amdgpu: fix the gfx hang while use per-ib secure flag (v2)

[Huang Rui]

Since 6643ba1 frame control packets are only issued in presence of secure IB(s).
This causes hangs on some hardware (eg: Raven1). This patch restores the
unconditionnal frame control packets issuing, that's to keep the per-IB logic
regarding the secure flag.

Fixes: 6643ba1 drm/amdgpu: Move to a per-IB secure flag (TMZ)

v1 -> v2:
As suggested by Luben, and accept part of implemetation from this patch:
- Put "secure" closed to the loop and use optimization
- Change "secure" to bool again, and move "secure == -1" out of loop.

Reported-and-Tested-by: Pierre-Eric Pelloux-Prayer 

Signed-off-by: Huang Rui 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   | 29 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  5 +++--
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 15 ---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 +++--
 4 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 4b2342d..0f4909a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -216,7 +216,14 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
amdgpu_ring_emit_cntxcntl(ring, status);
}
 
+   /* Setup initial TMZiness and send it off.
+*/
secure = false;
+   if (job && ring->funcs->emit_frame_cntl) {
+   secure = ib->flags & AMDGPU_IB_FLAGS_SECURE ? true : false;
+   amdgpu_ring_emit_frame_cntl(ring, true, secure);
+   }
+
for (i = 0; i < num_ibs; ++i) {
ib = [i];
 
@@ -228,27 +235,21 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
!amdgpu_sriov_vf(adev)) /* for SRIOV preemption, Preamble 
CE ib must be inserted anyway */
continue;
 
-   /* If this IB is TMZ, add frame TMZ start packet,
-* else, turn off TMZ.
-*/
-   if (ib->flags & AMDGPU_IB_FLAGS_SECURE && 
ring->funcs->emit_tmz) {
-   if (!secure) {
-   secure = true;
-   amdgpu_ring_emit_tmz(ring, true);
+   if (job && ring->funcs->emit_frame_cntl) {
+   if (!!secure ^ !!(ib->flags & AMDGPU_IB_FLAGS_SECURE)) {
+   amdgpu_ring_emit_frame_cntl(ring, false, 
secure);
+   secure = !secure;
+   amdgpu_ring_emit_frame_cntl(ring, true, secure);
}
-   } else if (secure) {
-   secure = false;
-   amdgpu_ring_emit_tmz(ring, false);
}
 
amdgpu_ring_emit_ib(ring, job, ib, status);
status &= ~AMDGPU_HAVE_CTX_SWITCH;
}
 
-   if (secure) {
-   secure = false;
-   amdgpu_ring_emit_tmz(ring, false);
-   }
+   if (job && ring->funcs->emit_frame_cntl)
+   amdgpu_ring_emit_frame_cntl(ring, false,
+   secure ? true : false);
 
 #ifdef CONFIG_X86_64
if (!(adev->flags & AMD_IS_APU))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 24caff0..4d019d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -166,7 +166,8 @@ struct amdgpu_ring_funcs {
void (*emit_reg_write_reg_wait)(struct amdgpu_ring *ring,
uint32_t reg0, uint32_t reg1,
uint32_t ref, uint32_t mask);
-   void (*emit_tmz)(struct amdgpu_ring *ring, bool start);
+   void (*emit_frame_cntl)(struct amdgpu_ring *ring, bool start,
+   bool secure);
/* priority functions */
void (*set_priority) (struct amdgpu_ring *ring,
  enum drm_sched_priority priority);
@@ -247,7 +248,7 @@ struct amdgpu_ring {
 #define amdgpu_ring_emit_wreg(r, d, v) (r)->funcs->emit_wreg((r), (d), (v))
 #define amdgpu_ring_emit_reg_wait(r, d, v, m) (r)->funcs->emit_reg_wait((r), 
(d), (v), (m))
 #define amdgpu_ring_emit_reg_write_reg_wait(r, d0, d1, v, m) 
(r)->funcs->emit_reg_write_reg_wait((r), (d0), (d1), (v), (m))
-#define amdgpu_ring_emit_tmz(r, b) (r)->funcs->emit_tmz((r), (b))
+#define amdgpu_ring_emit_frame_cntl(r, b, s) (r)->funcs->emit_frame_cntl((r), 
(b), (s))
 #define amdgpu_ring_pad_ib(r, ib) ((r)->funcs->pad_ib((r), (ib)))
 #define amdgpu_ring_init_cond_exec(r) (r)->funcs->init_cond_exec((r))
 #define amdgpu_ring_patch_cond_exec(r,o) (r)->funcs->patch_cond_exec((r),(o))
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 7b61583..748ac35 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ 

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

[Christian König]

Am 27.02.20 um 11:26 schrieb Nirmoy:


On 2/27/20 11:08 AM, Christian König wrote:



  scheds = adev->sdma.sdma_sched;
@@ -502,6 +507,24 @@ struct dma_fence *amdgpu_ctx_get_fence(struct 
amdgpu_ctx *ctx,

  return fence;
  }
  +static void amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx,
+    const u32 hw_ip,
+    enum drm_sched_priority priority)
+{
+    int i;
+
+    for (i = 0; i < amdgpu_ctx_num_entities[hw_ip]; ++i) {
+    if (!ctx->entities[hw_ip][i])
+    continue;
+
+    /* TODO what happens with prev scheduled jobs */


If we do it right, that should be unproblematic.

The entity changes the rq/scheduler it submits stuff to only when it 
is idle, e.g. no jobs on the hardware nor software queue.


So changing the priority when there is still work should be ok 
because it won't take effect until the entity is idle.

Thanks clarifying that.


Can of course be that userspace then wonders why the new priority 
doesn't take effect. But when you shoot yourself into the foot it is 
supposed to hurt, doesn't it?

 :D



+ drm_sched_entity_destroy(>entities[hw_ip][i]->entity);
+    amdgpu_ctx_fini_entity(ctx->entities[hw_ip][i]);
+
+    amdgpu_ctx_init_entity(ctx, AMDGPU_HW_IP_COMPUTE, i);


Well, that is most likely NOT the right way of doing it :) Destroying 
the entity with fini and reinit might cause quite a bunch of problems.


Could be that this works as well, but I would rather just assign 
sched_list and num_sched_list.


How about doing that with a new function like 
drm_sched_entity_modify_sched() ?


Yes, sounds like the sanest thing to as well.

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

[PATCH] drm/amdgpu/sriov: Use VF-accessible register for gpu_clock_count

[jianzh]

Navi12 VK CTS subtest timestamp.calibrated.dev_domain_test failed
because mmRLC_CAPTURE_GPU_CLOCK_COUNT register cannot be
written in VF due to security policy.

Solution: use a VF-accessible timestamp register pair
mmGOLDEN_TSC_COUNT_LOWER/UPPER for SRIOV case.

Signed-off-by: jianzh 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 44f00ec..8787a46 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -35,6 +35,8 @@
 
 #include "gc/gc_10_1_0_offset.h"
 #include "gc/gc_10_1_0_sh_mask.h"
+#include "smuio/smuio_11_0_0_offset.h"
+#include "smuio/smuio_11_0_0_sh_mask.h"
 #include "navi10_enum.h"
 #include "hdp/hdp_5_0_0_offset.h"
 #include "ivsrcid/gfx/irqsrcs_gfx_10_1.h"
@@ -3920,9 +3922,14 @@ static uint64_t gfx_v10_0_get_gpu_clock_counter(struct 
amdgpu_device *adev)
 
amdgpu_gfx_off_ctrl(adev, false);
mutex_lock(>gfx.gpu_clock_mutex);
-   WREG32_SOC15(GC, 0, mmRLC_CAPTURE_GPU_CLOCK_COUNT, 1);
-   clock = (uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_LSB) |
-   ((uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_MSB) << 
32ULL);
+   if (!amdgpu_sriov_vf(adev)) {
+   WREG32_SOC15(GC, 0, mmRLC_CAPTURE_GPU_CLOCK_COUNT, 1);
+   clock = (uint64_t)RREG32_SOC15(GC, 0, 
mmRLC_GPU_CLOCK_COUNT_LSB) |
+   ((uint64_t)RREG32_SOC15(GC, 0, 
mmRLC_GPU_CLOCK_COUNT_MSB) << 32ULL);
+   } else {
+   clock = (uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER) |
+   ((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER) << 32ULL);
+   }
mutex_unlock(>gfx.gpu_clock_mutex);
amdgpu_gfx_off_ctrl(adev, true);
return clock;
-- 
2.7.4

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

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

[Nirmoy]

On 2/27/20 11:08 AM, Christian König wrote:



  scheds = adev->sdma.sdma_sched;
@@ -502,6 +507,24 @@ struct dma_fence *amdgpu_ctx_get_fence(struct 
amdgpu_ctx *ctx,

  return fence;
  }
  +static void amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx,
+    const u32 hw_ip,
+    enum drm_sched_priority priority)
+{
+    int i;
+
+    for (i = 0; i < amdgpu_ctx_num_entities[hw_ip]; ++i) {
+    if (!ctx->entities[hw_ip][i])
+    continue;
+
+    /* TODO what happens with prev scheduled jobs */


If we do it right, that should be unproblematic.

The entity changes the rq/scheduler it submits stuff to only when it 
is idle, e.g. no jobs on the hardware nor software queue.


So changing the priority when there is still work should be ok because 
it won't take effect until the entity is idle.

Thanks clarifying that.


Can of course be that userspace then wonders why the new priority 
doesn't take effect. But when you shoot yourself into the foot it is 
supposed to hurt, doesn't it?

 :D



+ drm_sched_entity_destroy(>entities[hw_ip][i]->entity);
+    amdgpu_ctx_fini_entity(ctx->entities[hw_ip][i]);
+
+    amdgpu_ctx_init_entity(ctx, AMDGPU_HW_IP_COMPUTE, i);


Well, that is most likely NOT the right way of doing it :) Destroying 
the entity with fini and reinit might cause quite a bunch of problems.


Could be that this works as well, but I would rather just assign 
sched_list and num_sched_list.


How about doing that with a new function like 
drm_sched_entity_modify_sched() ?



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

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

[Christian König]

Am 26.02.20 um 21:37 schrieb Nirmoy Das:

We were changing compute ring priority while rings were being used
before every job submission which is not recommended. This patch
recreates entity with higher/normal priority sched list when user
changes ctx's priority.

high/normal priority sched list are generated from set of high/normal
priority compute queues. When there are no high priority hw queues then
it fall backs to software priority.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  4 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 58 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h  |  2 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  6 ---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c |  4 ++
  5 files changed, 59 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index f397ff97b4e4..8304d0c87899 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1205,7 +1205,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
struct drm_sched_entity *entity = p->entity;
enum drm_sched_priority priority;
-   struct amdgpu_ring *ring;
struct amdgpu_bo_list_entry *e;
struct amdgpu_job *job;
uint64_t seq;
@@ -1258,9 +1257,6 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
priority = job->base.s_priority;
drm_sched_entity_push_job(>base, entity);
  
-	ring = to_amdgpu_ring(entity->rq->sched);

-   amdgpu_ring_priority_get(ring, priority);
-
amdgpu_vm_move_to_lru_tail(p->adev, >vm);
  
  	ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence);

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 94a6c42f29ea..ea4dc57d2237 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -85,8 +85,13 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, 
const u32 hw_ip, const
num_scheds = 1;
break;
case AMDGPU_HW_IP_COMPUTE:
-   scheds = adev->gfx.compute_sched;
-   num_scheds = adev->gfx.num_compute_sched;
+   if (priority <= DRM_SCHED_PRIORITY_NORMAL) {
+   scheds = adev->gfx.compute_sched;
+   num_scheds = adev->gfx.num_compute_sched;
+   } else {
+   scheds = adev->gfx.compute_sched_high;
+   num_scheds = adev->gfx.num_compute_sched_high;
+   }
break;
case AMDGPU_HW_IP_DMA:
scheds = adev->sdma.sdma_sched;
@@ -502,6 +507,24 @@ struct dma_fence *amdgpu_ctx_get_fence(struct amdgpu_ctx 
*ctx,
return fence;
  }
  
+static void amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx,

+   const u32 hw_ip,
+   enum drm_sched_priority priority)
+{
+   int i;
+
+   for (i = 0; i < amdgpu_ctx_num_entities[hw_ip]; ++i) {
+   if (!ctx->entities[hw_ip][i])
+   continue;
+
+   /* TODO what happens with prev scheduled jobs */


If we do it right, that should be unproblematic.

The entity changes the rq/scheduler it submits stuff to only when it is 
idle, e.g. no jobs on the hardware nor software queue.


So changing the priority when there is still work should be ok because 
it won't take effect until the entity is idle.


Can of course be that userspace then wonders why the new priority 
doesn't take effect. But when you shoot yourself into the foot it is 
supposed to hurt, doesn't it?



+   drm_sched_entity_destroy(>entities[hw_ip][i]->entity);
+   amdgpu_ctx_fini_entity(ctx->entities[hw_ip][i]);
+
+   amdgpu_ctx_init_entity(ctx, AMDGPU_HW_IP_COMPUTE, i);


Well, that is most likely NOT the right way of doing it :) Destroying 
the entity with fini and reinit might cause quite a bunch of problems.


Could be that this works as well, but I would rather just assign 
sched_list and num_sched_list.



+
+   }
+}
  void amdgpu_ctx_priority_override(struct amdgpu_ctx *ctx,
  enum drm_sched_priority priority)
  {
@@ -515,12 +538,18 @@ void amdgpu_ctx_priority_override(struct amdgpu_ctx *ctx,
for (i = 0; i < AMDGPU_HW_IP_NUM; ++i) {
for (j = 0; j < amdgpu_ctx_num_entities[i]; ++j) {
struct drm_sched_entity *entity;
+   struct amdgpu_ring *ring;
  
  			if (!ctx->entities[i][j])

continue;
  
  			entity = >entities[i][j]->entity;

-   

Re: [RFC PATCH 2/3] drm/amdgpu: change hw sched list on ctx priority override

[Nirmoy]

Found two issues :

On 2/26/20 9:37 PM, Nirmoy Das wrote:

+static void amdgpu_ctx_hw_priority_override(struct amdgpu_ctx *ctx,
+   const u32 hw_ip,
+   enum drm_sched_priority priority)
+{
+   int i;
+
+   for (i = 0; i < amdgpu_ctx_num_entities[hw_ip]; ++i) {
+   if (!ctx->entities[hw_ip][i])
+   continue;
+
+   /* TODO what happens with prev scheduled jobs */
+   drm_sched_entity_destroy(>entities[hw_ip][i]->entity);
+   amdgpu_ctx_fini_entity(ctx->entities[hw_ip][i]);
+
+   amdgpu_ctx_init_entity(ctx, AMDGPU_HW_IP_COMPUTE, i);

s/AMDGPU_HW_IP_COMPUTE/hw_ip
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c

index 18e11b0fdc3e..4501ae7afb2e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -326,6 +326,10 @@ int amdgpu_ring_init(struct amdgpu_device *adev, struct 
amdgpu_ring *ring,
  
  	ring->max_dw = max_dw;

ring->priority = DRM_SCHED_PRIORITY_NORMAL;
+   if (ring->funcs->type == AMDGPU_RING_TYPE_COMPUTE &&
+   ring->funcs->init_priority)
I didn't set ring->priority to DRM_SCHED_PRIORITY_HIGH in the previous 
patch

+   ring->funcs->init_priority(ring);
+
mutex_init(>priority_mutex);
  
  	for (i = 0; i < DRM_SCHED_PRIORITY_MAX; ++i)

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

Re: [RFC PATCH 1/3] drm/amdgpu: implement ring init_priority for compute ring

[Christian König]

Am 27.02.20 um 10:57 schrieb Nirmoy:


On 2/27/20 5:44 AM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 3:34 PM Nirmoy Das  
wrote:
init_priority will set second compute queue(gfx8 and gfx9) of a pipe 
to high priority

and 1st queue to normal priority.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c    | 14 ++
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c    | 13 +
  3 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h

index 24caff085d00..a109373b9fe8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -170,6 +170,7 @@ struct amdgpu_ring_funcs {
 /* priority functions */
 void (*set_priority) (struct amdgpu_ring *ring,
   enum drm_sched_priority priority);
+   void (*init_priority) (struct amdgpu_ring *ring);
 /* Try to soft recover the ring to make the fence signal */
 void (*soft_recovery)(struct amdgpu_ring *ring, unsigned 
vmid);

 int (*preempt_ib)(struct amdgpu_ring *ring);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c

index fa245973de12..14bab6e08bd6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -6334,6 +6334,19 @@ static void 
gfx_v8_0_ring_set_priority_compute(struct amdgpu_ring *ring,

 gfx_v8_0_pipe_reserve_resources(adev, ring, acquire);
  }

+static void gfx_v8_0_ring_init_priority_compute(struct amdgpu_ring 
*ring)

+{
+   /* set pipe 0 to normal priority and pipe 1 to high priority*/
+   if (ring->queue == 1) {
+   gfx_v8_0_hqd_set_priority(ring->adev, ring, true);
+   gfx_v8_0_ring_set_pipe_percent(ring, true);
+   } else {
+   gfx_v8_0_hqd_set_priority(ring->adev, ring, false);
+   gfx_v8_0_ring_set_pipe_percent(ring, false);
+   }
+
+}

We should drop gfx_v8_0_hqd_set_priority() and set the priorities in
the mqd instead.  In gfx_v8_0_mqd_init(), set
mqd->cp_hqd_pipe_priority and mqd->cp_hqd_queue_priority as
appropriate for each queue.  I'm not sure we want to mess with
gfx_v8_0_ring_set_pipe_percent ultimately at all once this lands.
That stuff statically adjusts the priorities between gfx and compute.

Thanks Alex. I will send a updated patch for this.


Maybe wait a second with that I'm just going over patch #2.

Christian.




+
  static void gfx_v8_0_ring_emit_fence_compute(struct amdgpu_ring 
*ring,

  u64 addr, u64 seq,
  unsigned flags)
@@ -6967,6 +6980,7 @@ static const struct amdgpu_ring_funcs 
gfx_v8_0_ring_funcs_compute = {

 .insert_nop = amdgpu_ring_insert_nop,
 .pad_ib = amdgpu_ring_generic_pad_ib,
 .set_priority = gfx_v8_0_ring_set_priority_compute,
+   .init_priority = gfx_v8_0_ring_init_priority_compute,
 .emit_wreg = gfx_v8_0_ring_emit_wreg,
  };

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c

index 1c7a16b91686..0c66743fb6f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -5143,6 +5143,18 @@ static void 
gfx_v9_0_ring_set_priority_compute(struct amdgpu_ring *ring,

 gfx_v9_0_pipe_reserve_resources(adev, ring, acquire);
  }

+static void gfx_v9_0_ring_init_priority_compute(struct amdgpu_ring 
*ring)

+{
+   /* set pipe 0 to normal priority and pipe 1 to high priority*/
+   if (ring->queue == 1) {
+   gfx_v9_0_hqd_set_priority(ring->adev, ring, true);
+   gfx_v9_0_ring_set_pipe_percent(ring, true);
+   } else {
+   gfx_v9_0_hqd_set_priority(ring->adev, ring, false);
+   gfx_v9_0_ring_set_pipe_percent(ring, true);
+   }
+}

Same comment as above.

Alex


+
  static void gfx_v9_0_ring_set_wptr_compute(struct amdgpu_ring *ring)
  {
 struct amdgpu_device *adev = ring->adev;
@@ -6514,6 +6526,7 @@ static const struct amdgpu_ring_funcs 
gfx_v9_0_ring_funcs_compute = {

 .insert_nop = amdgpu_ring_insert_nop,
 .pad_ib = amdgpu_ring_generic_pad_ib,
 .set_priority = gfx_v9_0_ring_set_priority_compute,
+   .init_priority = gfx_v9_0_ring_init_priority_compute,
 .emit_wreg = gfx_v9_0_ring_emit_wreg,
 .emit_reg_wait = gfx_v9_0_ring_emit_reg_wait,
 .emit_reg_write_reg_wait = 
gfx_v9_0_ring_emit_reg_write_reg_wait,

--
2.25.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org

Re: [RFC PATCH 1/3] drm/amdgpu: implement ring init_priority for compute ring

[Nirmoy]

On 2/27/20 5:44 AM, Alex Deucher wrote:

On Wed, Feb 26, 2020 at 3:34 PM Nirmoy Das  wrote:

init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high 
priority
and 1st queue to normal priority.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 ++
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 13 +
  3 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 24caff085d00..a109373b9fe8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -170,6 +170,7 @@ struct amdgpu_ring_funcs {
 /* priority functions */
 void (*set_priority) (struct amdgpu_ring *ring,
   enum drm_sched_priority priority);
+   void (*init_priority) (struct amdgpu_ring *ring);
 /* Try to soft recover the ring to make the fence signal */
 void (*soft_recovery)(struct amdgpu_ring *ring, unsigned vmid);
 int (*preempt_ib)(struct amdgpu_ring *ring);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index fa245973de12..14bab6e08bd6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -6334,6 +6334,19 @@ static void gfx_v8_0_ring_set_priority_compute(struct 
amdgpu_ring *ring,
 gfx_v8_0_pipe_reserve_resources(adev, ring, acquire);
  }

+static void gfx_v8_0_ring_init_priority_compute(struct amdgpu_ring *ring)
+{
+   /* set pipe 0 to normal priority and pipe 1 to high priority*/
+   if (ring->queue == 1) {
+   gfx_v8_0_hqd_set_priority(ring->adev, ring, true);
+   gfx_v8_0_ring_set_pipe_percent(ring, true);
+   } else {
+   gfx_v8_0_hqd_set_priority(ring->adev, ring, false);
+   gfx_v8_0_ring_set_pipe_percent(ring, false);
+   }
+
+}

We should drop gfx_v8_0_hqd_set_priority() and set the priorities in
the mqd instead.  In gfx_v8_0_mqd_init(), set
mqd->cp_hqd_pipe_priority and mqd->cp_hqd_queue_priority as
appropriate for each queue.  I'm not sure we want to mess with
gfx_v8_0_ring_set_pipe_percent ultimately at all once this lands.
That stuff statically adjusts the priorities between gfx and compute.

Thanks Alex. I will send a updated patch for this.



+
  static void gfx_v8_0_ring_emit_fence_compute(struct amdgpu_ring *ring,
  u64 addr, u64 seq,
  unsigned flags)
@@ -6967,6 +6980,7 @@ static const struct amdgpu_ring_funcs 
gfx_v8_0_ring_funcs_compute = {
 .insert_nop = amdgpu_ring_insert_nop,
 .pad_ib = amdgpu_ring_generic_pad_ib,
 .set_priority = gfx_v8_0_ring_set_priority_compute,
+   .init_priority = gfx_v8_0_ring_init_priority_compute,
 .emit_wreg = gfx_v8_0_ring_emit_wreg,
  };

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 1c7a16b91686..0c66743fb6f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -5143,6 +5143,18 @@ static void gfx_v9_0_ring_set_priority_compute(struct 
amdgpu_ring *ring,
 gfx_v9_0_pipe_reserve_resources(adev, ring, acquire);
  }

+static void gfx_v9_0_ring_init_priority_compute(struct amdgpu_ring *ring)
+{
+   /* set pipe 0 to normal priority and pipe 1 to high priority*/
+   if (ring->queue == 1) {
+   gfx_v9_0_hqd_set_priority(ring->adev, ring, true);
+   gfx_v9_0_ring_set_pipe_percent(ring, true);
+   } else {
+   gfx_v9_0_hqd_set_priority(ring->adev, ring, false);
+   gfx_v9_0_ring_set_pipe_percent(ring, true);
+   }
+}

Same comment as above.

Alex


+
  static void gfx_v9_0_ring_set_wptr_compute(struct amdgpu_ring *ring)
  {
 struct amdgpu_device *adev = ring->adev;
@@ -6514,6 +6526,7 @@ static const struct amdgpu_ring_funcs 
gfx_v9_0_ring_funcs_compute = {
 .insert_nop = amdgpu_ring_insert_nop,
 .pad_ib = amdgpu_ring_generic_pad_ib,
 .set_priority = gfx_v9_0_ring_set_priority_compute,
+   .init_priority = gfx_v9_0_ring_init_priority_compute,
 .emit_wreg = gfx_v9_0_ring_emit_wreg,
 .emit_reg_wait = gfx_v9_0_ring_emit_reg_wait,
 .emit_reg_write_reg_wait = gfx_v9_0_ring_emit_reg_write_reg_wait,
--
2.25.0

___
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-gfxdata=02%7C01%7Cnirmoy.das%40amd.com%7Cdfeeaa22459548bb7b9808d7bb3fcb60%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183754987155471sdata=CUR%2BxoLBO%2FPSG7B1lyKAgQVcMLr%2BqQRYlHHs3OGFZPA%3Dreserved=0

___
amd-gfx mailing list