Re: What should bridge drivers use instead of __v4l2_subdev_state_alloc()?

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

Hi,

On 08/11/2026 12:25, Laurent Pinchart wrote:
> On Sat, Nov 07, 2026 at 05:31:06PM -0800, DelaySystem wrote:
>>
>> Hello,
>>
>> While working on drivers/staging/media/tegra-video I ran into the FIXME
>> above __tegra_channel_try_format() in vi.c (added by commit 40aaab9d773b
>> in 2022):
>>
>> 	/* FIXME: Drop this call, drivers are not supposed to use
>> 	 * __v4l2_subdev_state_alloc(). */
>>
>> The driver needs a scratch TRY state to negotiate formats with the remote
>> sensor subdev from video-node ioctl context, where no subdev file handle
>> exists. I looked for the intended replacement, but:
>>
>> - there is no non-dunder allocator in drivers/media or include/media;
>> - v4l2_subdev_call_state_try() is documented for legacy non-MC drivers
>>    only, has no in-tree users, and allocates one state per call, while the
>>    driver needs one state across enum_frame_size + set_fmt + get_crop;
>> - the active-state APIs have the wrong semantics here, since try_fmt must
>>    not disturb ACTIVE state;
>> - the same FIXME is still present in mainline vsp1 and staging atomisp,
>>    and mainline stm32-dcmi still calls the dunder directly, with (as far
>>    as I can tell) zero conversions since the 2022 rename.
>>
>> So my question: is a new core helper the intended direction for the
>> bridge-driver scratch-TRY-state case, and if so, is there any guidance
>> on the shape it should take? Or is there an existing pattern I missed?
>>
>> If a new helper is the answer, I am happy to implement it and convert
>> the in-tree users.
> 
> No, that's not the answer.
I think converting to MC is the answer. At least for a staging driver.

  Tomi