Hi Bryan, On Fri, May 8, 2026 at 12:06 PM Bryan O'Donoghue <[email protected]> wrote: > > On 07/05/2026 23:49, Loic Poulain wrote: > > +/** > > + * struct camss_isp_job_ops - per-job operation callbacks > > + * > > + * @ready: Optional; return %true if the job can be submitted to hardware. > > + * Called outside the scheduler spinlock. May be NULL (always > > ready). > > + * @run: Start the hardware for this job. Called from workqueue > > context. > > + * @ctx_changed is %true when this job differs from the previously > > + * run job (i.e. first run ever, or a different context took > > over). > > + * @abort: Optional; abort a running job (e.g. trigger a HW reset). > > + * Called from process context during camss_isp_sched_cancel(). > > + * May be NULL. > > + */ > > +struct camss_isp_job_ops { > > + bool (*ready)(void *priv); > > + void (*run)(void *priv, bool ctx_changed); > > + void (*abort)(void *priv); > > +}; > > I'll reiterate, I don't think this is needed and is overkill. > > v4l2_m2m_ops already has device_run(), job_abort() and job_ready(). > > :g/ISP_SCHED_PAUSED/s//v4l2_m2m->suspend()/resume()/g > > This seems like codebomb of a parallel implementation, which can be > largely covered by existing v4l2 stuff and if not then should be > justified in v4l2 as a new design paradigm.
I could potentially reuse the v4l2_m2m_ops structure for these operations, but not the full v4l2-m2m framework. The latter is quite monolithic and handles everything, buffers, queues, job scheduling, media topology, etc and is primarily designed for simple m2m devices (i.e. a single video node with two queues). As such, it doesn’t really fit ISP use case. Instead, the approach here is to introduce smaller, focused helpers to handle these orthogonal aspects (buffer management, scheduling, etc.), which aligns with the direction suggested by Laurent [1]. The longer-term goal would be to generalize these concepts at the V4L2/media framework level. At that point, drivers such as OPE or mali-c55 could be adapted to use the common infrastructure. [1] https://lore.kernel.org/all/[email protected]/
