hverkuil: It's only a small baby step - but the simple bug fix you highlighted in that mail from Julia regarding the dm365_resizer in staging looks good to me so I've added an RB tag. I can't undelegate from pinchartl though I'm afraid.
kbingham: I've redelegated that patch to me, so it will appear in a pull request Friday or Monday.
If there are more patches like that, just paste the patchwork link here and I'll do the same with them. Same with marking patches as superseded, just let me know.
sailus: are you there? I need some clarification about your review to my imx274 patch
lucaceresoli: I need to leave now, please send me an e-mail. Or we could continue tomorrow.
sailus: OK, I'm emailing, thanks
sailus: quick question if you have time, for multiplexed streams do you agree that the V4L2_CID_PIXEL_RATE controll should contain the aggregated pixel rate for all multiplexed streams going over a CSI-2 link?
neg, since we normally use the V4L2_CID_PIXEL_RATE value to accurately set up the DPHY I would hope so...
well I guess more accurately it would need to be the PIXEL_RATE on the egress port of the aggregator
neg: What would be the aggregated pixel rate?
Different parts of the frame can have different sample depths...
sailus: even so for one stream it can be represented as one number right? So if a CSI-2 bus carries two streams wonuld it not be the same as adding the pixel rate of those two together as the value exposed in PIXEL_RATE control?
I might have missunderstound what you tried to say with different saple depths for different parts of a single frame
neg: A frame in CSI-2 may contain multiple data types, i.e. sample depths.
And if there are multiple streams through a single pad, then it may well be that the pixel rate is not the same for all of them.
So it'd be nice to have a per-pad control, on the pads on the other side of the subdev, just as we have formats.
hverkuil: It seems the video-i2c was delegated to me in Patchwork. I thought you were going to apply the two patches to your tree?
sailus, in that case what would use to derive the byte clock we need to program the DPHY ths_term and the like?
sailus: ahh I now see where my confusion was, frame for me was just a frame in a single stream not for all. Thanks for clearifying
In the current prottype I'm summing-up all CSI-2 streams pixel rate into one larg number and is reporting that using PIXEL_RATE which I then use to configure the CSI-2 link on the recievier side
neg: The pixel rate is used e.g. to figure out whether the pipeline can handle such a rate. Other than that, it's just informational.
So it really would be per-stream in that case.
bparrot: LINK_FREQ control.
sailus, well that is not what is currently done in either ti-vpe/cal.c or omap3isp (which i used as a reference for cal)
Good.
why good?
The LINK_RATE control's value is unaffected what is transported on the link.
So it'll work with multiple concurrent streams over a single link.
Oh.
I think I missed "not" in your sentence. :-I
Yeah... there's just a single stream. Then using PIXEL_RATE isn't an issue.
so it the long run, sensor driver should provide both PIXEL_RATE and LINK_FREQ?
and it would better for us to use the LINK_FREQ to setup the CSI2 link?
I guess we'll need to figure out what to do with the pixel rate in case there are multiple streams; we don't have per-pad controls at the moment.
One option would be to implement support for those, of course.
a quick scan shows that sensor driver either provide one or the other rarely both
But I wonder how that approach scales in the control framework.
We might need more than that to make it clean.
The likely reason for that is that some receiver drivers have used one of them, and a sensor driver has been developed with a particular receiver driver so it has only received the one that's been needed.
in this case the actual pixel rate does not matter much, at least as far as setting the CSI2 link is concerned
Luckily it's easy to add such controls.
yeah i figured as much
right, so i'll have to update the way i am driving the byte clock to setup the link...
hi everyone
s/driving/deriving
is there anyone?
...
sailus: the V4L2 spec documents the relationship between LINK_FREQ and PIXEL_RATE
do you think that relationship will not be valid for multiplexed streams ?
pinchartl: It's defined to depend on the media bus code, but if you have multiple streams you don't have that media bus code either.
It could be a good idea to update that bit of documentation even if it's not entirely wrong either.
my point is
how does a receiver interpret the PIXEL_RATE control ?
what does it represent ?
currently it's the pixel clock after deserialization
what should it be with multiplexed streams ?
I suggested above specifying it for pads, just as the multi-stream support patchset does for formats..
But we don't have per-pad controls.
forget about per-pad controls for a moment, assume we can have them if we need them
if it's specified per pad
what does it represent ?
Pixel rate of the stream through that pad...?
please elaborate :-)
what is the pixel rate ?
Rate of pixels in a stream, isn't it?
I wonder if it's getting too late for today.
what is the rate of pixels ?
Something just reminded me of MegaHAL.
X-)
no, I'm serious, how do you define it ?
does it include blanking ?
or just the active pixels ?
It's directly calculated from the link frequency, without considering blanking.
That's how it actually needs to be: you can't otherwise calculate the frame time as described in the documentation. That will also need a revision with multiple streams actually.
I think it's indeed getting too late, you need to sleep :-)
Yes.
Let's continue tomorrow.
Or... just later today.
Hyvää yötä!
bonne nuit