On Wed Oct 28, 2026 at 11:31 AM JST, John Hubbard wrote: > On 10/27/26 12:35 AM, Alexandre Courbot wrote: >> The upcoming r000 firmware support [1] introduces a new type of command >> named GMC alongside the existing and already supported RPC command type. >> >> Since RPC was the only command type supported so far, it was embedded >> into the lowest command queue level: the message header actually >> includes the RPC header and the code considers them as one. >> >> This makes the r000/GMC support difficult to land without a refactor, >> with the result of transport layer code being duplicated between the two >> message types, and no clear separation between the RPC and GMC code >> which are mixed together in the command queue. Merging the code that way >> would introduce quite some technical debt. >> >> Thus, this series prepares a proper landing ground for a new message >> type by extracting all the RPC layer code and moving it into its own >> sub-modules, making the `cmdq` module completely agnostic of the type of >> message it transports. >> >> With the transport and message layers properly separated, support for >> GMC can be added into sibling modules of `rpc`, and the transport layer >> can be converted once when doing the switch to r000. >> >> This moves quite a bit of code around, but most of it is moved verbatim. >> No significant functional change is intended. >> >> For the r000 series, this essentially means the following: >> >> - Its patch 7 making `allocate_command` generic can be dropped as the >> transport layer makes no assumption about the message type. >> - Patches adding GMC support will do it in dedicated `gmc` sub-modules, >> following the model set by RPC. These `gmc` sub-modules will start as >> `dead_code` as they are being built. >> - The "switch to r000" patch will essentially operate on the transport >> layer level, i.e. `cmdq.rs`. >> - There should be no need for extra post-switch RPC fixing, as the >> transport layer code will already be shared with GMC. >> >> Overall, this should make the r000 series much easier to review and >> eventually land, while not creating new technical debt. >> >> This revision fixes the latest nits while addressing a couple more >> issues found by Sashiko. >> >> This series is based on `drm-rust-next`. >> >> [1] https://lore.kernel.org/all/[email protected]/ >> >> Signed-off-by: Alexandre Courbot <[email protected]> >> --- >> Changes in v6: >> - Add comment to `consume_element`'s documentation to disambiguate it. >> (Eliot) >> - Add a patch to avoid sleeping in `drain` when reaching the end of the >> queue. (Sashiko) >> - Fix badly-formatted import block. (Sashiko) >> - Link to v5: >> https://patch.msgid.link/[email protected] > > Hi Alex, looks like it is converging, are you planning to merge soon? > Or do you need more reviewers to weigh in?
I was planning to give this (hopefully final) a couple days on the list to check that the r000 rebase on it is viable (which it seems to be!), so unless someone screams I will merge it very soon.
