What should bridge drivers use instead of __v4l2_subdev_state_alloc()?

What should bridge drivers use instead of __v4l2_subdev_state_alloc()?

[DelaySystem]

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.

Thank you,
DelaySystem

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

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

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

[Tomi Valkeinen]

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

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

[Laurent Pinchart]

On Sun, Nov 08, 2026 at 06:05:34PM +0200, Tomi Valkeinen wrote:
> 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.

Note that usage of LLMs is not allowed in drivers/staging/

-- 
Regards,

Laurent Pinchart