search for: r535_gsp_rpc_poll

...veau_sched ever > > being initialized in the first place. > > Thanks, I've confirmed that these patches do fix the problem. Looks like I spoke too soon, I just hit the problem with the drm-next tree. I'm able to repro the problem by having r535_gsp_init() return an error. r535_gsp_rpc_poll return -EINVAL (I'm testing my own GSP-RM build) and nouveau_sched_fini() is called even though nouveau_sched_init() was never called.

...len %d < %zd\n", > - msg->length, sizeof(*msg) + repc); > + msg->length, sizeof(*msg) + > + gsp_rpc_len); > r535_gsp_msg_dump(gsp, msg, NV_DBG_ERROR); > r535_gsp_msg_done(gsp, msg); > return ERR_PTR(-EIO); > @@ -414,7 +420,8 @@ r535_gsp_rpc_poll(struct nvkm_gsp *gsp, u32 fn) > } > > static void * > -r535_gsp_rpc_send(struct nvkm_gsp *gsp, void *argv, bool wait, u32 repc) > +r535_gsp_rpc_send(struct nvkm_gsp *gsp, void *argv, bool wait, > + u32 gsp_rpc_len) > { > struct nvfw_gsp_rpc *rpc = container_of(argv...

Hi folks: Here is the leftover of the previous spin of NVKM GSP RPC fixes, which is handling the return of large GSP message. PATCH 1 and 2 in the previous spin were merged [1], and this spin is based on top of PATCH 1 and PATCH 2 in the previous spin. Besides the support of the large GSP message, kernel doc and many cleanups are introduced according to the comments in the previous spin [2].