mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil+cisco@kernel.org>
To: Mattijs Korpershoek <mkorpershoek@kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Michael Riesch <michael.riesch@collabora.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Maxime Ripard <mripard@kernel.org>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/5] media: Fault-Tolerant V4L2
Date: Tue, 10 Nov 2026 13:08:05 +0100	[thread overview]
Message-ID: <685c60fb-f209-42e8-8d75-7e65ca5353c9@kernel.org> (raw)
In-Reply-To: <xhkdby0boob5n.fsf@mkorpers-koolstof.csb>

On 23/10/2026 14:26, Mattijs Korpershoek wrote:
> Hi everyone,
> 
> On Thu, Oct 01, 2026 at 14:55, Mattijs Korpershoek <mkorpershoek@kernel.org> wrote:
> 
>> On media-centric camera pipelines, every entity is known at boot time
>> and described statically (for example via device-tree).
>>
>> The V4L2 framework assumes that every entity of the camera
>> pipeline is always present. This is a reasonable assumption for
>> integrated cameras in laptops or phones. However, in automotive systems,
>> cameras (e.g. rear-view or surround-view) can be damaged or disconnected.
>> When the framework assumes all sensors are present, a single missing
>> camera can prevent the entire pipeline from operating.
> 
> This series has been discussed at the Camera & ISP "unconference" in
> Pragues (during Linux Plumbers)
> 
> The notes can be found here:
> https://lore.kernel.org/linux-media/20261021224119.GA383235@killaraus.ideasonboard.com/T/#u

What is missing in this discussion is how userspace can indicate that it
actually can handle partially instantiated pipelines.

Today if one or more parts do not come up, the devices nodes are also not
created. This is typically exactly what you want. But here you allow partial
instantiation, and how does userspace signal that? It must be an 'opt-in'
mechanism, but how is that done? There are no devices yet, so that can't
be used, so what alternatives are there?

We've been discussion Fault Tolerant V4L2 for many years now, and every time
I raise this issue, but I never received any proposals.

This must be solved.

Regards,

	Hans

> 
> I intend to rework V2 based on the feedback I've received on the list
> and at the "unconference".
> 
> I'll try to reuse Sakari's work on media graph events from:
> https://git.linuxtv.org/sailus/media_tree.git/log/?h=partial-reg
> 
> Thanks again for the feedback I've received so far.



  reply	other threads:[~2026-11-10 12:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 12:55 Mattijs Korpershoek
2026-10-01 12:55 ` [PATCH RFC 1/5] media: imx219: Move LP-11 state switch to power_on() Mattijs Korpershoek
2026-10-01 17:03   ` Dave Stevenson
2026-10-01 12:55 ` [PATCH RFC 2/5] media: v4l2-subdev: Add new ioctl for connection status Mattijs Korpershoek
2026-10-02  7:13   ` Sakari Ailus
2026-10-02  8:53     ` Mattijs Korpershoek
2026-10-01 12:55 ` [PATCH RFC 3/5] media: imx219: Allow driver probe with missing sensor Mattijs Korpershoek
2026-10-01 16:50   ` Dave Stevenson
2026-10-01 17:35     ` Dave Stevenson
2026-10-02 12:21       ` Mattijs Korpershoek
2026-10-01 12:55 ` [PATCH RFC 4/5] media: imx219: Implement .detect() sensor operation Mattijs Korpershoek
2026-10-01 12:55 ` [PATCH RFC 5/5] media: imx219: Add status polling using .detect() Mattijs Korpershoek
2026-10-01 15:58   ` Dave Stevenson
2026-10-01 17:26     ` Dave Stevenson
2026-10-02  8:39       ` Mattijs Korpershoek
2026-10-02  7:21     ` Sakari Ailus
2026-10-02  8:45       ` Mattijs Korpershoek
2026-10-02  8:32     ` Mattijs Korpershoek
2026-10-23 12:26 ` [PATCH RFC 0/5] media: Fault-Tolerant V4L2 Mattijs Korpershoek
2026-11-10 12:08   ` Hans Verkuil [this message]
2026-11-10 12:33     ` Maxime Ripard
2026-11-10 13:30       ` Hans Verkuil
2026-11-10 14:17         ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=685c60fb-f209-42e8-8d75-7e65ca5353c9@kernel.org \
    --to=hverkuil+cisco@kernel.org \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=michael.riesch@collabora.com \
    --cc=mkorpershoek@kernel.org \
    --cc=mripard@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®