STRUCT DCMIPP_ENT_DEVICE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct_dcmipp_ent_device(9) πŸ’…

okay so bestie, welcome to the Kernel API Manual β€” this is the page for struct dcmipp_ent_device, and it's literally the core struct that represents a node in the topology. yes, THE core one. main character energy fr fr 🌟


✨ NAME ✨

struct dcmipp_ent_device β€” the core struct that represents a node in the topology 🫢


πŸŽ€ SYNOPSIS πŸŽ€

struct dcmipp_ent_device {
    struct media_entity *ent;
    struct media_pad *pads;
    struct v4l2_mbus_config_parallel bus;
    enum v4l2_mbus_type bus_type;
    irq_handler_t handler;
    irqreturn_t handler_ret;
    irq_handler_t thread_fn;
 };

like, that's the whole shape of it. no cap πŸ’…


🌸 Members 🌸

  • ent β€” the pointer to struct media_entity for the node. it's giving "where am i in the topology" energy πŸ¦‹
  • pads β€” the list of pads of the node. all of them. every single pad πŸŽ€
  • bus β€” a struct v4l2_mbus_config_parallel describing the input bus πŸ”Œ
  • bus_type β€” type of input bus (parallel or BT656). iykyk πŸ‘€
  • handler β€” irq handler dedicated to the subdev ⚑
  • handler_ret β€” value returned by the irq handler πŸ“¬
  • thread_fn β€” threaded irq handler 🧡

πŸ’– Description πŸ’–

so here's the vibe: the DCMIPP provides a single IRQ line and a IRQ status registers for all subdevs. yep, ONE line for everybody. so once the main irq handler (registered at probe time) is called, it will chain calls to the irq handler of each the subdevs of the pipelines, using the handler/handler_ret/thread_fn variables. it's a whole relay race, honestly πŸƒβ€β™€οΈ

Each node of the topology must create a dcmipp_ent_device struct. literally every node. Depending on the node it will be of an instance of v4l2_subdev or video_device struct where both contains a struct media_entity. Those structures should embedded the dcmipp_ent_device struct through v4l2_set_subdevdata and video_set_drvdata respectivaly, allowing the dcmipp_ent_device struct to be retrieved from the corresponding struct media_entity. see what they did there? embedding so you can always find your way back home 🏑✨

ngl, the embedding-through-v4l2_set_subdevdata-and-video_set_drvdata thing is the whole trick β€” that's how the dcmipp_ent_device gets retrieved back out of the struct media_entity. iconic behavior, tbh πŸ‘‘

πŸ‘‘ SEE ALSO πŸ‘‘

Kernel file ./drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-common.h plus the whole friend group:


and that's the page bestie!! 🌈 mwah πŸ’‹ this one came from ./drivers/media/platform/st/st... and it's dated October 2026, so like, future vibes only β­πŸ¦‹ go forth and build your topology nodes, you've got this πŸ’œ

πŸ“¦ where this page comes from