< pinchartl> welcome to the multimedia meeting
< pinchartl> Topic 1. Status Check for the Multimedia Tasks
<pinchartl> * Geert
<pinchartl> Since last meeting:
<pinchartl> - Investigated an ADV7511 s2ram crash, to discover a DRM EDID bug
<pinchartl> Until next meeting: None
<pinchartl> Issues and blockers: None
<pinchartl> geertu: any comment ?
<geertu> It seems the i2c bus is locked up
<geertu> and on subsequent reset, EDID cannot be read, too  [17:06]
<pinchartl> Wolfram mentioned he would investigate on the I2C side
<pinchartl> I have another display bug reported by Morimoto-san to handle
<pinchartl> so I'll happily ignore the adv7511 for now :-) until Wolfram
	    completes his investigations (or I fix the other bug)  [17:07]
<geertu> Yeah, I saw that. Could that be fw_devlink?
<pinchartl> I doubt it  [17:08]
<wsa> pinchartl: that will be an interesting race :)
<pinchartl> :-)  [17:09]
<pinchartl> * Jacopo
<pinchartl> Since last meeting:
<pinchartl> - V4L2 multiplexed streams support for GMSL - review and
	    discussion of v4l2-mux support from Tomi - R-Car CSI-2 + GMSL
	    ported to v4l2-mux
<pinchartl> - R-Car ISP review
<pinchartl> Until next meeting:
<pinchartl> - New version of v4l2-mux with VIN channels properly handled
<pinchartl> Issues and blockers: None
<pinchartl> jmondi: any comment ?
<jmondi> pinchartl: not really, apart from the point I mentioned in C)
<pinchartl> I've added it to the discussion points
<jmondi> thanks
<pinchartl> thank you
<jmondi> let's keep it for later  [17:10]
<pinchartl> * Kieran
<pinchartl> Since last meeting:
<pinchartl> - Investigate V3U display timings
<pinchartl> Until next meeting:
<pinchartl> - Investigate V3U display timings
<pinchartl> Peripheral clock confirmed, but still need to dig in and verify
	    things here.
<pinchartl> Issues and blockers: None
<pinchartl> Kieran is on vacation this week, I don't think he's with us today
<pinchartl> I've been working with him on the V3U display, so I can try to
	    answer questions if there are any
<pinchartl> * Laurent  [17:11]
<pinchartl> Since last meeting:
<pinchartl> - Upstreamed pending patches
<pinchartl> Most notably, sent pull requests for V3U support in DU, and for
	    non-contiguous buffer import.
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> Continued working with Tomi Valkeinen. Still work in progress (v9
	    is out). Reviewed Jacopo's MAX9286 multiplexed streams support.
<pinchartl> - Tested HDMI probe issue with v5.15-rc1
<pinchartl> Couldn't reproduce on M3-N Salvator-XS, will test on ULCB next.
<pinchartl> Until next meeting:
<pinchartl> - Debug HDMI probe issue on v5.15-rc1
<pinchartl> - V4L2 multiplexed streams development
<pinchartl> Issues and blockers: None
<pinchartl> any question ?
<moriperi> thank you for checking HDMI issue  [17:12]
<pinchartl> you're welcome. now I have to dust my ULCB :-)
<pinchartl> * Morimoto-san
<pinchartl> Since last meeting:
<pinchartl> - Posted ALSA SoC new generic sound card driver
<pinchartl> Maintainer said basically OK, got some feedback about from
	    non-maintainer, posted v4.
<pinchartl> Until next meeting:
<pinchartl> - Continue ALSA SoC work
<pinchartl> Issues and Blockers:
<pinchartl> - v5.15-rc1 doesn't probe HDMI
<pinchartl> Issue reported to Laurent and to mailing list.
<pinchartl> moriperi: any comment ?
<moriperi> nothing, thanks
*** damm (~damm@167.99.4.198) has quit: Remote host closed the connection
								        [17:13]
*** damm (~damm@167.99.4.198) has joined channel #periperi
<pinchartl> * Niklas
<pinchartl> Since last meeting:
<pinchartl> - [PATCH] media: rcar-vin: Use user proved buffers when starting
<pinchartl> - [PATCH v3] media: staging: max96712: Add basic support for
	    MAX96712 GMSL2 deserializer
<pinchartl> - [PATCH v5] media: rcar-isp: Add Renesas R-Car Image Signal
	    Processor driver
<pinchartl> - [PATCH v2 0/2] rcar-csi2: Serialize format cfg and improve mutex
	    handling
<pinchartl> - [PATCH v6] media: rcar-isp: Add Renesas R-Car Image Signal
	    Processor driver
<pinchartl> Until next meeting:
<pinchartl> - Follow up pending patches
<pinchartl> Issues and blockers: None
<pinchartl> neg: any comment ?
<neg> No comment
<pinchartl> thank you  [17:14]
<pinchartl> that's it for the MM status update unless I've forgotten someone
<pinchartl> Topic 2. Discussions
<pinchartl> - R-Car VIN channel handling for v4l2-mux  [17:15]
<pinchartl> jmondi: what is that about ?
<jmondi> so, I've implemented support for multiplxing and CSI-2 VC routing on
	 max9286 and R-Car CSI-2
<jmondi> the part I am missing, and from a brief discussion we had I am
	 probably misunderstanding, is the VIN part  [17:16]
<jmondi> as we all know VIN has a CHSEL register with a fixed number of
	 combinations
<jmondi> it is currently populated inspecting the enabled links between CSI-2
	 and the VIN instances which are used to build a mask of enabled
	 routes  [17:17]
<jmondi> afaiu this does not take into account which VC is routed to the CSI-2
	 source pad linked to the VIN instance at hand  [17:18]
<jmondi> I can make an example
<neg> From a multiplexed stream PoV just ignore that the CHSEL register exists
      ;-)
<jmondi> how so ?
<neg> The documentation is missleading and it have nothing to do with VC, it
      just configure which parallel bus on the CSI-2 soruce side is routed to
      which VIN instance  [17:19]
<jmondi> from what I see empirically, it also have an impact on filtering
<jmondi> I can make an example
<neg> VC only exists on the CSI-2 sink pad and inside the CSI-2 driver where a
      VC is routed to a physical source pad (aka parallel bus) that faces the
      VIN  [17:20]
<jmondi> on V3M, have a look at the chsel table (page 2006 of datasheet 2.20)
<jmondi> I am configuring the CSI-2 interface to route VC0 on source pad#1 and
	 VC1 to source pad #4  [17:21]
<jmondi> this in my understanding corresponds to the first row of the chsel
	 table
<jmondi> the way the chsel mask building procedure works leads to a chsel mask
	 of value 0x3  [17:22]
<jmondi> which expects VC3 to be on pad #4, not VC1
<jmondi> in my mind that could be solved by inspecting the CSI-2 frame desc,
	 and configuring the mask accordingly  [17:23]
<jmondi> but I got from the two of you that chsel should not be involved with
	 routing
<jmondi> unfortunately, if I stick with the computed chsel=0x3 VIN3 output is
	 blank  [17:24]
<jmondi> if I instead use a chsel value of 0x00 I get good images
<neg> The CHSEL value calculation don't care about VC, it only looks at the
      media graph links  [17:26]
<jmondi> I understand, and that's the culprit of my issues, but I got from our
	 previous discussions that the mask building procedure should not be
	 changed  [17:27]
<neg> If you first disable all MC links and then enable CSI40.sourcepad0 ->
      VIN0 and CSI40.sourcepad4 -> VIN3 and don't get a CHSEL value of 0x00
      there is a bug in VIN
<neg> and that of course shall be fixed
<neg> But this bug would then exists today and would not depend on any
      multiplexed stream work  [17:28]
<jmondi> I don't think it's a bug, I think the current procedure assumes
	 CSI40.sourcepad4 = VC3
*** wsa (~wsa@p54b33006.dip0.t-ipconnect.de) has quit: Quit: cya!  [17:29]
<neg> d00h, yes I got confused that in your multiplexed work you break that
      assumtion ;-)  [17:32]
<jmondi> and also, inspecting the enabled links is not enough, as in example
	 to dishern if (in the same example I've given) on CSI40.pad#4 you
	 have VC1 or embedded data. you should inspect the frame desc
<neg> But this is good news then, I had been mening to try if what you
      descirbe here works
<jmondi> (even if I don't get why VC and datatype are mixed there)
<jmondi> I mean, we might assume the [VC, CSI source pad] association is fixed
								        [17:33]
<neg> Because if it do we could simplify the VIN routing I think, as we could
      allow any VIN to be routed to any VC
<jmondi> but it would limit the HW supported features
<jmondi> yeah, well, considering the limited number of possible routes each
	 SoC supports :)  [17:34]
<neg> I'm thinking a hardcoded CHSEL value and immutable links between CSI-2
      and VIN. The routing of VC to VIN is controlled by the multiplexed API
      inside the CSI-2  [17:35]
<pinchartl> can that be done ?  [17:36]
<pinchartl> are the other options than CHSEL to control routing ?
<jmondi> didn't get the question :)
<pinchartl> s/are the/are there/  [17:37]
<neg> If I understood Jacopo this is what he does in his multiplexed stream
      series and this is why he see this issue
<jmondi> my understanding is that CHSEL does not control routing but rather
	 filtering  [17:38]
<neg> As he "routes VC1 to source pad #4" he breaks the assumtion we had that
      each VC was mapped to a fixed pad VCn -> source pad n
<jmondi> and that surprises me as it means the VIN has the notion of VC/DT
<jmondi> while I always assumed there's just a parallel data bus between VIN
	 and CSI-2  [17:39]
<pinchartl> how do you control routing within the CSI-2 receiver ?
<jmondi> through which registers you mean ?
<pinchartl> yes
<neg> VCDT and VCDT2
<neg> SEL_VC - These bits specify the virtual channels for channel 0 to
      capture. SEL_VC2 - These bits specify the virtual channels for channel 1
      to capture.  [17:41]
<jmondi> give me a sec I should re-look into my patches
<jmondi> I think Laurent is asking how this is handled according to the
	 routing API
<pinchartl> that is interesting indeed  [17:42]
<pinchartl> especially the mention of the TAG signal
<pinchartl> which would imply that the output of the CSI-2 has a tag for each
	    sample
<neg> So with a multiplexd stream API we could set what VC to output for which
      channel and have a fixed immutable CSI-2 to VIN remving much of the need
      for the horrible VIN group design
<pinchartl> I still think the CHSEL routes CSI-2 channels, not CSI-2 VC/DT
<pinchartl> would it be fair to conclude that more tests are needed ?  [17:44]
<pinchartl> to check more combinations of parameter
<neg> I think so, but it's an interesting find
<pinchartl> s
<jmondi> I would welcome a shared testing strategy  [17:46]
<pinchartl> how so ? by sharing testing, or by discussing the strategy ?
								        [17:47]
*** damm (~damm@167.99.4.198) has quit: Remote host closed the connection
								        [17:48]
*** damm (~damm@167.99.4.198) has joined channel #periperi
<neg> I thought about this a while back and wanted to start to test if what
      Jacopo now reports even was possibe using VCDT  [17:49]
<jmondi> I'm thinking about a shared plan about -what- to test  [17:50]
<neg> The next step was my dream of removing the horrid routing limitations
      between VIN and CSI-2, back then I thought about using media links, but
      if multiplexed streams is on the way maybe S/G_ROUTING would have been
      my first experiment as I think it would be simpler  [17:51]
<neg> If I where to test this I would force a static CHSEL from VIN, one CSI-2
      output channel to each VIN and then see if I can using VCDT route a
      single VC to each VIN and if that works move on to use more streams
								        [17:52]
*** damm (~damm@167.99.4.198) has quit: Ping timeout: 256 seconds  [17:53]
<neg> If that works I think we can start to bikeshed about how to best make
      use of it. But I think a first step is to make sure it works as a
      prototype
<pinchartl> could the two of you coordinate on the test strategy then ?
								        [17:54]
<jmondi> sure
<jmondi> if there's any interest in me continuing with this activty ofc
<pinchartl> I'm certainly interested :-)  [17:55]
<pinchartl> we have an odd hardware setup, and making sure it can be properly
	    supported with the new API is important
<jmondi> ok then
<jmondi> I think it's mostly about me and niklas agreeing on a time to work
	 together on this if he has bandwidth  [17:56]
<neg> I'm extatic about anything that can reduce the complexity and get rid of
      the VIN groups ;-)  [17:57]
<jmondi> ok, so let's sync to do some work and discussions on this then
<neg> sounds good
<jmondi> thanks
<pinchartl> :-)  [17:58]
<pinchartl> thank you
<pinchartl> any other discussion topic for today ?
<jmondi> no thanks :)
<jmondi> at least not from me ?
<neg> I'm good
<pinchartl> I thus propose adjourning the meeting. does anyone second ?
								        [17:59]
<neg> +1
<jmondi> +1 thank you all  [18:00]
<neg> Thanks all have a great day
<pinchartl> meeting adjourned
<pinchartl> thank you all for attending
<shimoday> thank you all. bye!  [18:02]