STRUCT S5P_MFC_DEV(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct s5p_mfc_dev(9) β€” Kernel API Manual πŸ’–

okay so picture this: it's the kernel API manual, it's the struct s5p_mfc_dev, and it's the struct holding all the driver's internal parameters. everything. the whole vibe. one big beautiful bag of state and we're gonna go through it together, bestie 🫢


✨ NAME ✨

struct s5p_mfc_dev β€” the struct that contains all the driver's internal parameters, no cap πŸ’…


🌸 SYNOPSIS 🌸

struct s5p_mfc_dev {
    struct v4l2_device      v4l2_dev;
    struct video_device     *vfd_dec;
    struct video_device     *vfd_enc;
    struct platform_device  *plat_dev;
    struct device           *mem_dev[BANK_CTX_NUM];
    void __iomem            *regs_base;
    int irq;
    struct v4l2_ctrl_handler dec_ctrl_handler;
    struct v4l2_ctrl_handler enc_ctrl_handler;
    struct s5p_mfc_pm       pm;
    const struct s5p_mfc_variant    *variant;
    int num_inst;
    spinlock_t irqlock;
    spinlock_t condlock;
    struct mutex mfc_mutex;
    int int_cond;
    int int_type;
    unsigned int int_err;
    wait_queue_head_t queue;
    struct s5p_mfc_priv_buf fw_buf;
    size_t mem_size;
    dma_addr_t mem_base;
    unsigned long *mem_bitmap;
    void *mem_virt;
    dma_addr_t dma_base[BANK_CTX_NUM];
    unsigned long hw_lock;
    struct s5p_mfc_ctx *ctx[MFC_NUM_CONTEXTS];
    int curr_ctx;
    unsigned long ctx_work_bits;
    atomic_t watchdog_cnt;
    struct timer_list watchdog_timer;
    struct workqueue_struct *watchdog_workqueue;
    struct work_struct watchdog_work;
    unsigned long enter_suspend;
    struct s5p_mfc_priv_buf ctx_buf;
    int warn_start;
    const struct s5p_mfc_hw_ops *mfc_ops;
    const struct s5p_mfc_hw_cmds *mfc_cmds;
    const struct s5p_mfc_regs *mfc_regs;
    enum s5p_mfc_fw_ver fw_ver;
    bool fw_get_done;
    bool risc_on;
};

like, look at her. main character energy fr fr πŸ‘‘


πŸŽ€ Members πŸŽ€

every single field, one by one, so you never have to guess what's what:

  • v4l2_dev β€” type v4l2_device. the v4l2_device, obviously πŸ’…
  • vfd_dec β€” the video device for decoding
  • vfd_enc β€” the video device for encoding
  • plat_dev β€” the platform device
  • mem_dev β€” the child devices of the memory banks
  • regs_base β€” the base address of the MFC hw registers
  • irq β€” the irq resource
  • dec_ctrl_handler β€” the control framework handler for decoding
  • enc_ctrl_handler β€” the control framework handler for encoding
  • pm β€” power management control
  • variant β€” MFC hardware variant information
  • num_inst β€” counter of active MFC instances
  • irqlock β€” the lock for operations on videobuf2 queues
  • condlock β€” the lock for changing/checking if a context is ready to be processed
  • mfc_mutex β€” the lock for video_device
  • int_cond β€” variable used by the waitqueue
  • int_type β€” the type of the last interrupt
  • int_err β€” the error number for the last interrupt
  • queue β€” the waitqueue for waiting for completion of device commands
  • fw_buf β€” the firmware buffer data structure
  • mem_size β€” the size of the firmware operation memory
  • mem_base β€” the base DMA address of the firmware operation memory
  • mem_bitmap β€” the bitmap for managing MFC internal buffer allocations
  • mem_virt β€” the virtual address of the firmware operation memory
  • dma_base β€” the address of the beginning of memory banks
  • hw_lock β€” used for hardware locking
  • ctx β€” the array of driver contexts
  • curr_ctx β€” the number of the currently running context
  • ctx_work_bits β€” used to mark which contexts are waiting for hardware
  • watchdog_cnt β€” the counter for the watchdog
  • watchdog_timer β€” the timer for the watchdog
  • watchdog_workqueue β€” the workqueue for the watchdog
  • watchdog_work β€” the worker for the watchdog
  • enter_suspend β€” the flag set when entering suspend
  • ctx_buf β€” the common context memory (MFCv6)
  • warn_start β€” the hardware error code from which warnings start
  • mfc_ops β€” the ops structure holding HW operation function pointers
  • mfc_cmds β€” the cmd structure holding HW commands function pointers
  • mfc_regs β€” the structure holding MFC registers
  • fw_ver β€” the loaded firmware sub-version
  • fw_get_done β€” the flag set when request_firmware is complete and copied into fw_buf
  • risc_on β€” the flag indicating whether RISC is on or off
ngl there's a lot of locks in there β€” irqlock, condlock, mfc_mutex, hw_lock β€” and they're all doing different jobs. don't mix them up, bestie 😭

πŸ¦‹ SEE ALSO πŸ¦‹

  • the kernel file ./drivers/media/platform/samsung/s5p-mfc/s5p_mfc_common.h
  • struct s5p_mfc_priv_buf(9)
  • struct s5p_mfc_ctx(9)

that's the whole tour, and honestly? she ate. πŸ“

this page came from ./drivers/media/platform/samsu... β€” dated October 2026, struct s5p_mfc_dev(9) πŸ’œ slay, go read the headers now ✨

πŸ“¦ where this page comes from