From: Zhi Wang <zhiw@nvidia.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: <nouveau@lists.freedesktop.org>, <airlied@gmail.com>,
<daniel@ffwll.ch>, <dakr@kernel.org>, <bskeggs@nvidia.com>,
<acurrid@nvidia.com>, <cjia@nvidia.com>, <smitra@nvidia.com>,
<ankita@nvidia.com>, <aniketa@nvidia.com>, <kwankhede@nvidia.com>,
<targupta@nvidia.com>, <zhiwang@kernel.org>,
Nouveau <nouveau-bounces@lists.freedesktop.org>
Subject: Re: [PATCH 2/5] drm/nouveau/nvkm: factor out the current RPC command reply policies
Date: Wed, 12 Feb 2025 21:56:34 +0200 [thread overview]
Message-ID: <20250212215634.00006430@nvidia.com> (raw)
In-Reply-To: <D7Q9QSYHW7D7.2GCEXYDRVSMUR@nvidia.com>
On Wed, 12 Feb 2025 15:55:08 +0900
"Alexandre Courbot" <acourbot@nvidia.com> wrote:
> On Sat Feb 8, 2025 at 2:58 AM JST, Zhi Wang wrote:
> > There can be multiple cases of handling the GSP RPC messages, which are
> > the reply of GSP RPC commands according to the requirement of the callers
> > and the nature of the GSP RPC commands.
> >
> > The current supported reply policies are "callers don't care" or "receive
> > the entire message" according to the requirement of the caller. For
> > introducing a new policy, factor out the current RPC command reply
> > polices.
> >
> > Factor out NVKM_GSP_RPC_REPLY_RECV as "receive the entire message". If
> > none is specified, the default is "callers don't care".
> >
> > No functional change is intended.
> >
> > Signed-off-by: Zhi Wang <zhiw@nvidia.com>
> > ---
> > .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 16 +++++---
> > .../gpu/drm/nouveau/nvkm/subdev/bar/r535.c | 2 +-
> > .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 41 +++++++++++--------
> > .../drm/nouveau/nvkm/subdev/instmem/r535.c | 2 +-
> > 4 files changed, 36 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
> > index 746e126c3ecf..c467e44cab47 100644
> > --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
> > +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
> > @@ -31,6 +31,10 @@ typedef int (*nvkm_gsp_msg_ntfy_func)(void *priv, u32 fn, void *repv, u32 repc);
> > struct nvkm_gsp_event;
> > typedef void (*nvkm_gsp_event_func)(struct nvkm_gsp_event *, void *repv, u32 repc);
> >
> > +enum {
> > + NVKM_GSP_RPC_REPLY_RECV = 1,
> > +};
>
> Let's turn this into a named type and add a variant for the 0 value, e.g.
>
> enum nvkm_gsp_rpc_reply_type {
> NVKM_GSP_RPC_DONT_CARE = 0,
> NVKM_GSP_RPC_REPLY_RECV = 1,
> }
>
> and use this type instead of an integer in the client code. This will
> make the compiler warn us if we try to pass an unexpected value.
>
> (DONT_CARE needs to be defined to something less ambiguous, I left it
> as-is because I don't really understand the intent behind this name :))
>
Thanks for the idea.
I was struggling to come up with a perfect name as well. DONT_CARE was on
the list, but it seems so heavy when considering that DONT_CARE is the
most common case and not looking ideal when it spreads to the call sites. :)
Probably I will go with NOWAIT.
> > +
> > struct nvkm_gsp {
> > const struct nvkm_gsp_func *func;
> > struct nvkm_subdev subdev;
> > @@ -188,7 +192,7 @@ struct nvkm_gsp {
> >
> > const struct nvkm_gsp_rm {
> > void *(*rpc_get)(struct nvkm_gsp *, u32 fn, u32 argc);
> > - void *(*rpc_push)(struct nvkm_gsp *, void *argv, bool wait, u32 repc);
> > + void *(*rpc_push)(struct nvkm_gsp *gsp, void *argv, int reply, u32 repc);
> > void (*rpc_done)(struct nvkm_gsp *gsp, void *repv);
> >
> > void *(*rm_ctrl_get)(struct nvkm_gsp_object *, u32 cmd, u32 argc);
> > @@ -255,9 +259,9 @@ nvkm_gsp_rpc_get(struct nvkm_gsp *gsp, u32 fn, u32 argc)
> > }
> >
> > static inline void *
> > -nvkm_gsp_rpc_push(struct nvkm_gsp *gsp, void *argv, bool wait, u32 repc)
> > +nvkm_gsp_rpc_push(struct nvkm_gsp *gsp, void *argv, int reply, u32 repc)
> > {
> > - return gsp->rm->rpc_push(gsp, argv, wait, repc);
> > + return gsp->rm->rpc_push(gsp, argv, reply, repc);
> > }
> >
> > static inline void *
> > @@ -268,13 +272,13 @@ nvkm_gsp_rpc_rd(struct nvkm_gsp *gsp, u32 fn, u32 argc)
> > if (IS_ERR_OR_NULL(argv))
> > return argv;
> >
> > - return nvkm_gsp_rpc_push(gsp, argv, true, argc);
> > + return nvkm_gsp_rpc_push(gsp, argv, NVKM_GSP_RPC_REPLY_RECV, argc);
> > }
> >
> > static inline int
> > -nvkm_gsp_rpc_wr(struct nvkm_gsp *gsp, void *argv, bool wait)
> > +nvkm_gsp_rpc_wr(struct nvkm_gsp *gsp, void *argv, int reply)
> > {
> > - void *repv = nvkm_gsp_rpc_push(gsp, argv, wait, 0);
> > + void *repv = nvkm_gsp_rpc_push(gsp, argv, reply, 0);
> >
> > if (IS_ERR(repv))
> > return PTR_ERR(repv);
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
> > index 3a30bea30e36..90186f98065c 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
> > @@ -56,7 +56,7 @@ r535_bar_bar2_update_pde(struct nvkm_gsp *gsp, u64 addr)
> > rpc->info.entryValue = addr ? ((addr >> 4) | 2) : 0; /* PD3 entry format! */
> > rpc->info.entryLevelShift = 47; //XXX: probably fetch this from mmu!
> >
> > - return nvkm_gsp_rpc_wr(gsp, rpc, true);
> > + return nvkm_gsp_rpc_wr(gsp, rpc, NVKM_GSP_RPC_REPLY_RECV);
> > }
> >
> > static void
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> > index 1ed7d5624a56..bc8eb9a3cb28 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> > @@ -584,25 +584,32 @@ r535_gsp_rpc_poll(struct nvkm_gsp *gsp, u32 fn)
> > }
> >
> > static void *
> > -r535_gsp_rpc_handle_reply(struct nvkm_gsp *gsp, u32 fn, bool wait,
> > +r535_gsp_rpc_handle_reply(struct nvkm_gsp *gsp, u32 fn, int reply,
> > u32 gsp_rpc_len)
>
> So here 'int reply' would become 'enum nvkm_gsp_rpc_reply_type reply'
> (and propagate to other callers).
>
> > {
> > struct nvfw_gsp_rpc *msg;
> > void *repv = NULL;
> >
> > - if (wait) {
> > + if (!reply)
> > + return NULL;
> > +
> > + switch (reply) {
> > + case NVKM_GSP_RPC_REPLY_RECV:
> > msg = r535_gsp_msg_recv(gsp, fn, gsp_rpc_len);
> > if (!IS_ERR_OR_NULL(msg))
> > repv = msg->data;
> > else
> > repv = msg;
> > + break;
> > + default:
> > + repv = ERR_PTR(-EINVAL);
> > + break;
> > }
>
> With the introduced type, this would become:
>
> switch (reply) {
> case NVKM_GSP_RPC_DONT_CARE:
> /* Works as repv is NULL already */
> break;
> case NVKM_GSP_RPC_REPLY_RECV:
> msg = r535_gsp_msg_recv(gsp, fn, gsp_rpc_len);
> if (!IS_ERR_OR_NULL(msg))
> repv = msg->data;
> else
> repv = msg;
> break;
> }
>
> I'm not sure whether you still need a 'default' arm? The compiler is
> happy without it, and since you control all the call sites nothing funny
> can happen without a dirty cast.
>
> > -
>
> No need to remove this separator line IMHO.
>
next prev parent reply other threads:[~2025-02-12 19:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 17:58 [PATCH 0/5] NVKM GSP RPC message handling policy Zhi Wang
2025-02-07 17:58 ` [PATCH 1/5] drm/nouveau/nvkm: factor out r535_gsp_rpc_handle_reply() Zhi Wang
2025-02-12 6:32 ` Alexandre Courbot
2025-02-07 17:58 ` [PATCH 2/5] drm/nouveau/nvkm: factor out the current RPC command reply policies Zhi Wang
2025-02-12 6:55 ` Alexandre Courbot
2025-02-12 19:56 ` Zhi Wang [this message]
2025-02-07 17:58 ` [PATCH 3/5] drm/nouveau/nvkm: introduce new GSP reply policy NVKM_GSP_RPC_REPLY_POLL Zhi Wang
2025-02-12 6:57 ` Alexandre Courbot
2025-02-12 13:33 ` Danilo Krummrich
2025-02-12 19:59 ` Zhi Wang
2025-02-07 17:58 ` [PATCH 4/5] drm/nouveau/nvkm: use the new policy for NV_VGPU_MSG_FUNCTION_ALLOC_MEMORY Zhi Wang
2025-02-07 17:58 ` [PATCH 5/5] drm/nouveau/nvkm: introduce a kernel doc for GSP message handling Zhi Wang
2025-02-12 6:59 ` Alexandre Courbot
2025-02-12 13:36 ` [PATCH 0/5] NVKM GSP RPC message handling policy Danilo Krummrich
2025-02-20 20:48 ` Ben Skeggs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250212215634.00006430@nvidia.com \
--to=zhiw@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=acurrid@nvidia.com \
--cc=airlied@gmail.com \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=bskeggs@nvidia.com \
--cc=cjia@nvidia.com \
--cc=dakr@kernel.org \
--cc=daniel@ffwll.ch \
--cc=kwankhede@nvidia.com \
--cc=nouveau-bounces@lists.freedesktop.org \
--cc=nouveau@lists.freedesktop.org \
--cc=smitra@nvidia.com \
--cc=targupta@nvidia.com \
--cc=zhiwang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.