Hi Jacopo,

On 23/07/2021 13:21, Jacopo Mondi wrote:

quoted

This current series version has a routing table, set with the set-routing
ioctl. When the routing is set, you could think that a set of "virtual" pads
is created (identified by (pad, stream) pair), where each route endpoint has
a pad. Those pads can then be configured similarly to the "normal" pads.

And that's for routes inside an entity. Am I wrong that in this
version multiplexed (or virtual) pads identified by the (pad, stream)
pair have a format assigned at both ends of a link ?

Yes, that is correct.

quoted

quoted

quoted

quoted

     Also link validation is of course a bit more complex as shown by
     731facccc987 ("v4l: subdev: Take routing information into account in link validation")
     which was part of the previous series, but it's totally up to the
     core..

Moving everything to the pads by adding a 'stream' field basically
makes all pads potentially multiplexed, reducing the problem of format
configuration/validation to a 1-to-1 {pad, stream} pair validation
which allows to collapse the topology and maintain the current one.

Yes. I think I have problem understanding the counter arguments as I don't
really see a difference with a) two subdevs, each with two non-multiplexed
pads, linked 1-to-1 and b) two subdevs, each with one multiplexed pad, with
two routes.

My main concerns are:

- Usage of format configuration to establish routing as per above.
    Format assignment gets a routing semantic associated, which is an
    implicit behavior difficult to control and inspect for applications.

Again, either I'm totally misunderstanding what you're saying, or you are
talking about the method that has not been implemented.

For routing internal to entities as you said GS_ROUTING is still in
place, so my argument is moot. However I think it still applies to
multiplexed ends of a cross-entity link (see below).

quoted

quoted

- Userspace is in control of connecting endpoints on the multiplexed
    bus by assigning formats, this has two consequences:
    - A 1-to-1 mapping between streams on the two sides of the
      multiplexed bus which prevents routing multiple streams to the
      same endpoint (is this correct ?)

No, you can have multiple streams with the same endpoint (i.e. the same
(pad, stream) for source/sink side).

quoted

    - As the only information about a 'stream' on the multiplexed bus is
      the format it transports, it is required to assign to the stream
      identifier a semantic (ie stream 0 = virtual channel 0). The
      previous version had the information of what's transported on the
      multiplexed bus hidden from userspace and delegated to the
      frame_desc kAPI. This way it was possible to describe precisely
      what's sent on the bus, with bus-specific structures (ie struct
      v4l2_mbus_frame_desc_entry.bus.csi2)

That is how it's in this series too. The difference is that in the previous
version, when a driver needed to know something about the stream which was
not in the frame_desc, it had to start traversing the graph to find out a
non-multiplexed pad. With this version the driver has the information in its
(pad, stream) pair.

That's a (desirable) consequence of the fact multiplexed ends of a
link have a format assigned, right ?

Yes.

quoted

quoted

    - This might seem a bit pedantic, but, setting image formats and
      sizes on the endpoints of a multiplexed bus such as CSI-2 is not
      technically correct. CSI-2 transports packets tagged with
      identifiers for the virtual channel and data type they transport
      (and identifiers for the packet type, but that's part of the bus
      protocol). The format and size is relevant for configuring the
      size of the memory area where the receiver dumps the received
      packets, but it's not part of the link configuration itself.
      This was better represented by using the information from the
      remote side frame_desc.

Why is a multiplexed CSI-2 bus different than a non-multiplexed parallel
bus? Or more specifically, why is a single stream in a multiplexed CSI-2 bus
different than the stream in non-multiplexed parallel bus? It's the same
data, transported in a slightly different manner.

One could, of course, argue that they are not different, and pad
configuration for non-multiplexed pads should also be removed.

While I get where you're going, I don't completely agree. The format
set on the ends of a non-multiplexed link does not represent what is
transported there but instructs the receiver (less so the transmitter)
about what data it should expects to receive and allows drivers to
prepare for it. The same doesn't apply to multiplexed pads, where
'what is expected to receive' is given by the union of the formats of
the several (pad, stream) endpoints. Assuming my understanding is
correct, that's what I don't like about having formats on multiplexed
pads.

Hmm, I don't quite understand your point. Do you mean that in 
non-multiplexed case the format is used to configure the receiver 
hardware, whereas with multiplexed case that is not true?

The format describes the content of a stream. In non-multiplexed case 
there's only one stream. In both cases the frame-desc can be used to 
find out details about the transmission.

Maybe this becomes more clear if you can give some practical examples to 
highlight your concerns?

Thanks, this helps. Do we concur that the main difference between the
two version (let's call them v0 and v1) at least from an uAPI perspective,

Let's rather call them v1 and v2, as I've uesd those terms elsewhere 
already =)

is basically that the ends of a multiplexed link:

- in v0 had no formats assigned, configuration of the receiver end was
   performed in-kernel through get_frame_desc()

Yes, although if the driver needs to know details found in the format, 
it has to traverse through the graph to find the data.

- in v1 each (pad, stream) has a format assigned by userspace and the
   receiver configuration is deduced from the formats assigned to the
   several endpoints ?

The receiver configuration needs to be decided based on frame desc, 
formats, link freq control. This is the same for v0.

I would like to thank you for having bear with me so far and clarify my
doubts, I hope you'll find energy to clarify my last questions
here and I hope my understanding is not completely wrong, this is a
non-easy topic to deal with.

This will perhaps be easier to understand when I provide the drivers 
I've been using for testing. I'll do that for the next version.

However, I don't want to continue to argue because what I care about
is getting to have some solution merged, and I feel this discussion is
not getting any productive for that. What I can offer, if anyway

I disagree, I think it is productive =). I am relatively new to cameras 
and V4L2, so it's important to get opinions. It is also good to get 
questions so that I have to explain what I'm doing, as it often forces 
me to re-think topics that I have already "finished".

helpful, is in the next weeks (or months?) rebase the work we've done
on R-Car in the past to support VC multiplexing on your series to have
more material for comparison. Then the ideal solution would be to pick

This is a good idea, but please wait until the next version of the 
series. While there are currently no changes in the concepts, there are 
quite a lot of kernel side changes due to the new subdev state and using 
that.

a conference/event most of the interested parties could attend, sit
down for a few days and find a way to move forward. The linux-media
mini conferences held around ELC/plumbers had this purpose and helped
finalize direction for other topics in the past. Considering the
current situation that's very unlikely to happen, but a virtual
version of the same could be considered.

I'm happy to have meetings, one-to-one or bigger ones, to discuss this.

  Tomi