STRUCT VSP1_ISP_JOB_DESC(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct vsp1_isp_job_desc(9) πŸ’–

okay bestie, welcome to the struct vsp1_isp_job_desc(9) page from the Kernel API Manual β€” this one's all about describing a VSPX buffer transfer request, and honestly? it's giving "small struct, big responsibilities" energy. let's get into it 🫢

✨ NAME ✨

struct vsp1_isp_job_desc β€” literally just describes a VSPX buffer transfer request. that's the whole vibe. πŸ’…

🌸 SYNOPSIS 🌸

struct vsp1_isp_job_desc {
    struct {
      unsigned int pairs;
      dma_addr_t mem;
    } config;
    struct {
      struct v4l2_pix_format_mplane fmt;
      dma_addr_t mem;
    } img;
    struct vsp1_dl_list *dl;
 };

here's the whole squad, member by member πŸ‘‘

πŸŽ€ Members πŸŽ€

  • config β€” the ConfigDMA buffer descriptor. this is the config crew's home base πŸ’–
  • config.pairs β€” how many reg-value pairs are chilling in the ConfigDMA buffer. count 'em, bestie πŸ”’
  • config.mem β€” the bus address of the ConfigDMA buffer. so like, where it actually lives πŸ“
  • img β€” the RAW image buffer descriptor. the image side of things πŸ–ΌοΈ
  • img.fmt β€” the RAW image format. what shape the pixels are in 🌈
  • img.mem β€” the bus address of the RAW image buffer. found it, marked it πŸ“Œ
  • dl β€” pointer to the display list, populated by the VSPX driver inside the vsp1_isp_job_prepare function. main character pointer energy tbh 🌟

πŸ¦‹ Description πŸ¦‹

so what IS this thing? it describes a transfer request for the VSPX to perform on behalf of the ISP. that's the whole point. the job descriptor holds an optional ConfigDMA buffer and one RAW image buffer. 🫑

⚠️ okay this part matters SO much, pay attention: set config.pairs to 0 if no ConfigDMA buffer should be transferred. the minimum number of config.pairs that can be written using ConfigDMA is 17. a number of pairs < 16 corrupts the output image 😭. a number of pairs == 16 freezes the VSPX operation πŸ’€. so if the ISP driver has to write less than 17 pairs, it shall pad the buffer with writes directed to registers that have no effect β€” or just avoid using ConfigDMA entirely for those tiny write sequences. no cap, this is not optional lore.

the ISP driver shall pass an instance of this type to the vsp1_isp_job_prepare function, which will populate the display list pointer dl using the config and img descriptors. then, when the job has to be run on the VSPX, the descriptor shall be passed to vsp1_isp_job_run, which consumes the display list. πŸ”₯

and if you've got job descriptors that haven't been run yet? they shall be released with a call to vsp1_isp_job_release when stopping the streaming β€” because that's how the resources acquired by vsp1_isp_job_prepare get properly released. don't leave them hanging, bestie, that's rude πŸ™ˆ

🌟 SEE ALSO 🌟

  • Kernel file ./include/media/vsp1.h
  • struct vsp1_du_lif_config(9)
  • struct vsp1_du_atomic_config(9)
  • enum vsp1_du_crc_source(9)
  • struct vsp1_du_crc_config(9)
  • struct vsp1_du_writeback_config(9)
  • struct vsp1_du_atomic_pipe_config(9)
  • struct vsp1_isp_buffer_desc(9)
  • struct vsp1_vspx_frame_end(9)

and that's the page!! πŸŽ€ this one came from ./include/media, dated October 2026, and it's the struct vsp1_isp_job_desc(9) manual page β€” go forth and pad those buffers correctly, ily, bye πŸ’œβœ¨

πŸ“¦ where this page comes from