path: root/wiki/Chat_log/20210218-mm-chatlog

< pinchartl> welcome to the multimedia group chat meeting
< pinchartl> Topic 1. Status Check for the Multimedia Tasks	        [18:03]
< pinchartl> * Geert
<pinchartl> Since last meeting:
<pinchartl> - Alternative version to support ov7725 sensors on
	    r8a7742-iwg21d-q7-dbcm
<pinchartl> No feedback from Prabhakar
<pinchartl> Until next meeting: None
<pinchartl> Issues and blockers: None
<pinchartl> geertu: any comment ?
<geertu> pinchartl: no comments					        [18:04]
<geertu> will ping Prabhakar
<pinchartl> I haven't followed, why was an alternative version needed ? is
	    there anything we need to discuss ?
<geertu> pinchartl: The original patch was not very flexible. The user can mix
	 and match cameras on all 4 interfaces, so I wanted to support that.
								        [18:05]
<pinchartl> ok
<pinchartl> thanks
<pinchartl> * Jacopo
<pinchartl> Since last meeting:
<pinchartl> - RDACM21 support merged (in v5.12 ;D ) with a bit of pushing [1]
<pinchartl> - Eagle GMSL DT integration sent
<pinchartl> - GMSL reliability testing
<pinchartl> Run hundreds of boot cycles test to assest GMSL initialization
	    reliability abusing Kieran's remote lab :)
<pinchartl> [PATCH 00/16] media: i2c: GMSL reliability improvements
<pinchartl> Until next meeting:
<pinchartl> - Investigate Mauro's request to make max9271 an i2c driver
<pinchartl> - periject BSP ticket patch sweep
<pinchartl> - Investigate IMR patches in the new ticket
<pinchartl> Issues and blockers: None
<pinchartl> jmondi: any comment ?
<jmondi> not really, we can discuss mauro's request
<pinchartl> I'll add it to discussion points			        [18:06]
<pinchartl> thanks
<jmondi> and I will have questions for japeri about IMR, but that's better
	 handled by email
<pinchartl> * Kieran
<pinchartl> Since last meeting:
<pinchartl> - Identified CMA memory leak introduced in v5.11-rcX
<pinchartl> Issue bisected, reported, and fix tested.
<pinchartl> - GMSL testing and review
<pinchartl> - V3U received, and set up - and running on BristolBoardFarm
<pinchartl> Access already provided to Geert and Jacopo. Others can be set up,
<pinchartl> please ask.
<pinchartl> - Initial testing on V3U
<pinchartl> - Looked into GMSL2 and cabling requirements for V3U
<pinchartl> Until next meeting:
<pinchartl> - Further testing and completion of the V3U VSP/DU integration
<pinchartl> Issues and blockers: None
<pinchartl> kbingham: any comment ?
<kbingham> That will do ;-)
<pinchartl> thanks
<pinchartl> * Laurent
<pinchartl> Since last meeting:
<pinchartl> - Improved V4L2 async notifier API
<pinchartl> - Resumed V4L2 multiplexed streams development
<pinchartl> - GMSL2 planning discussions			        [18:07]
<pinchartl> - Found distributor for GMSL2 quad HFM cables
<pinchartl> - Shipped V3U board to Kieran
<pinchartl> Morimoto-san isn't our only paperwork person anymore.
<pinchartl> Until next meeting:
<pinchartl> - Follow up on 3D LUT API proposal for DRM/KMS
<pinchartl> - Periject triage for display
<pinchartl> - GMSL2 planning
<pinchartl> Issues and blockers: None
<pinchartl> any question ?
<moriperi> Nice paperwork :)
<kbingham> You mean you are also the paperwork guy?
<kbingham> I had to pay VAT on the import but no duties and customs, so I
	   think your paperwork was successful ;-)
<pinchartl> * Morimoto-san					        [18:09]
<pinchartl> Since last meeting:
<pinchartl> - Posting ALSA SoC cleanup patches
<pinchartl> It is almost in the final stage, finally.
<pinchartl> - Brush up new sound card driver
<pinchartl> - Request new sound test command to Ulrich		        [18:10]
<pinchartl> Ulrich has previously created a sound test, but it stopped working
	    at
<pinchartl> some point. A new test has been requested (which may be a simpler
	    tool).
<pinchartl> Until next meeting:
<pinchartl> - Port ALSA cleanup patches
<pinchartl> - Brush up new sound card driver
<pinchartl> Issues and Blockers: None
<pinchartl> moriperi: any comment ?
<moriperi> nothing, thanks
<pinchartl> thank you
<pinchartl> * Niklas
<pinchartl> Since last meeting:
<pinchartl> [PATCH v2 0/4] rcar-csi2: Update handling of transfer error
<pinchartl> Until next meeting:
<pinchartl> - Sort out pending patches and triage periject
<pinchartl> - Start VIN, CSI-2 and ISP capture prototype for V3U
<pinchartl> Issues and blockers: None
<pinchartl> neg: any comment ?
<neg> I have no comments at this time :-)
<pinchartl> thanks :-)						        [18:11]
<pinchartl> * Ulrich
<pinchartl> Since last meeting: None
<pinchartl> Until next meeting:
<pinchartl> - atest improvements
<pinchartl> Add support for more than 2 channels and sample sizes != 16 bits.
<pinchartl> Issues and blockers: None
<pinchartl> uli__: any comment ?
<uli__> moriperi: is the dependency on libsndfile a problem for your use case?
<uli__> if so, i can add it to the repo and statically link it, or use
	something else altogether				        [18:12]
<uli__> i'd just like to know before i continue
<pinchartl> I've captured that in the notes, let's move on until Morimoto-san
	    finds his keyboard again :-)			        [18:14]
<pinchartl> Topic 2. Discussions
<pinchartl> - GMSL2 cables
<moriperi> uli__: I'm not sure which one is related to the previous atest
<pinchartl> we now have a relatively cheap option for GMSL2 cable
<pinchartl> damm: we need an answer from you on this topic
<uli__> moriperi: the new atest uses libsndfile to read/write files
<moriperi> I'm using buildroot mainly. It is useful for me if new one works on
	   it.							        [18:15]
<uli__> should be ok then. i'll check, though.			        [18:16]
<uli__> thanks
<moriperi> thanks
<pinchartl> and while waiting for Magnus to get the keyboard back from
	    Morimoto-san,
<pinchartl> - I2C driver for MAX9271
<pinchartl> jmondi: feel free to speak
<damm> hi guys, so for the cables, can you tell us the estimated total cost
       here?							        [18:17]
<damm> that way mori/shimo can give ack/nack			        [18:18]
<jmondi> pinchartl: I'll let the cable discussion end first :)
<kbingham> ~$200 per board plus shipping, ?
<pinchartl> damm:
	    https://www.avnet.com/shop/us/products/avnet-engineering-services/l02-027-1000-z-zzzz-v2-3074457345635644755/
<damm> sorry i dont recall the total number of boards
<kbingham> 1 here, and don't you have one damm ?
<pinchartl> $69 / cable + shipping				        [18:19]
<pinchartl> up to 3 cables per V3U
<damm> yeah and some board is in transit
<damm> so 3 boards and 3 cables - a total of 10 would suffice?
<pinchartl> it should, yes					        [18:20]
<damm> so shall we make two orders of 6 cables to have a bit of failover?
<damm> or four orders of 3 cables
<kbingham> it probably makes sense to get cables ordered directly to where
	   they are needed.
<pinchartl> it would likely be cheaper for each board owner to buy their own
	    cables
<damm> or one order of 12 =)
<pinchartl> otherwise we'll have to ship them ourselves, and that's usually
	    more expensive
<damm> ok lets decide that
<pinchartl> so green light for Kieran to order 3 cables ?	        [18:21]
<damm> from my side for sure
<pinchartl> and invoicing it to Jinzai ? :-)
<damm> i'll make sure to order cables for the other ones
<damm> good question =)						        [18:22]
<damm> do we have any multimedia member that has a contract with opensource
       ab?
<neg> We do :-)							        [18:23]
<damm> if so the cost can just be added to the invoice
<neg> Silly question, do the RDACM2{0,1} modules fit the new cables ?
<pinchartl> neg: yes they do
<damm> is it possible for neg and pinchartl to figure out the money situation
       if neg sends an invoice?					        [18:24]
<neg> Sure we figure it
<pinchartl> so is the recommendation for Niklas to order the cables with
	    Kieran's address as the destination ?
<damm> interesting
<pinchartl> that minimzes paperwork
<damm> i'd like to route them through a french speaking country to reduce
       potential complexity					        [18:25]
<damm> just kidding
<pinchartl> can't help with that I'm afraid, Finland is still not French
	    speaking despite my efforts
<neg> I was hoping to hand carry them thru the Caribbeans
<jmondi> I can throw the italian postal service in the mix if you want to
	 reduce the potential shipment complexity
<damm> i think niklas can decide to ship them wherever he wants	        [18:26]
<neg> Guess I can pick the French side of St Marten
<damm> just give a receipt with the invoice
<neg> damm: Will do
<damm> that should solve the cable situation for EU side?
<damm> thanks
<pinchartl> yep
<damm> neg: let me know what you end up ordering		        [18:27]
<pinchartl> jmondi: back to MAX9271
<neg> damm: Sure, aim is to get 3 cables directly shipped to kbingham
<jmondi> sure							        [18:28]
<jmondi> well, you know the issue
<jmondi> (apart from me breaking -next two times :)
<kbingham> only twice ?
<jmondi> in a row!
<pinchartl> anything to discuss ? or will you just investigate first ?
<jmondi> quick recap: Mauro wants the max9271 to be made a full i2c driver
								        [18:29]
<jmondi> with the camera modules instantiating a new i2c device for that, and
	 communication with the serializer implemented used a regular kAPI
<jmondi> instead of function calls
<jmondi> I don't see any real gain if not pleasing him, but I understand the
	 current design is 'unusual'				        [18:30]
<jmondi> ack to investigate on that side ?
<pinchartl> I think it would make sense to have such a design for cameras that
	    are saner (no MCU). investigating what could be done in that case
	    is a good idea					        [18:31]
<pinchartl> then the investigation could be pushed to see if we could also
	    address the rdacm20 and rdacm21
<pinchartl> or if we need to keep the current architecture for those
<pinchartl> does it make sense ?
<jmondi> the part that worries me is the reprogramming of the i2c address more
	 than the MCU						        [18:32]
<pinchartl> the goal of the investigation is to figure out if there are
	    blockers :-)					        [18:33]
<jmondi> and the fact that to configure the gmsl specific paramters the
	 current v4l2-subdev kAPI might not be enough
<jmondi> so yeah, trying to see how it pans out makes sense imho
<pinchartl> the V4L2 subdev API could be extended if needed
<pinchartl> let's investigate to see what would be needed	        [18:34]
<jmondi> yep
<pinchartl> and then we can decide if it's worth the effort
<pinchartl> still on the topic of GMSL
<pinchartl> jmondi: you have reported three issues last time:
<pinchartl> - MAX9271 probe issue (where reprogramming the chip wasn't enough
	    to recover from failures)
<pinchartl> - RDACM20 startup (circular dependency between regulator and GPIO
	    controller)						        [18:35]
<pinchartl> - RDACM20 startup delay (which seemed not to be needed on Eagle)
<pinchartl> have those been investigated and/or solved ?
<jmondi> yes, investigate for sure				        [18:36]
<jmondi> it's in the "GMSL reliability
<jmondi> sorry, "GMSL reliability testing" part
<jmondi> the series I've sent tries to reduce the part of initialization which
	 is run without noise immunit protection activated
<jmondi> and even if not perfect, on a 50 boot cycle tests I had 6 failures
	 iirc							        [18:37]
<pinchartl> that's way too high
<jmondi> it was 20%
<pinchartl> and I'm not sure if noise immunity is really the culprit here
<pinchartl> are you in an environment so noisy that the camera would fail in
	    12% of the tests ? :-)				        [18:38]
<jmondi> ask Kieran, board is in his lab :)
<jmondi> remember powering goes through the same cables that transport data
<geertu> jmondi: Does the driver notice the failure? Can it retry? Does it
	 succeed on retry?					        [18:39]
<pinchartl> yes, and that's by design
<pinchartl> it's supposed to work
<geertu> It's coax, so it should be fairly immune to noise
<pinchartl> geertu: it's the first issue I've listed, retrying doesn't work
<pinchartl> or didn't work at least
<jmondi> geertu: the driver notices the failure, but the error seems to be
	 unrecoverable
<pinchartl> jmondi: are the three issues still affecting us then ?
<jmondi> I've never been able to recover a failure on identifying max9271
								        [18:40]
<jmondi> also, the time between power-on and power-off seems to play a role
<jmondi> pinchartl: failure in identifying max9271 are still not recoverable,
	 but I haven't seen any with the new design
<jmondi> the circular dependency on regulator and GPIO controller has been
	 solved with a gpio hog as it was done in Kieran's early integration
								        [18:41]
<pinchartl> didn't you say you saw 6 failures in 50 boots ?
<jmondi> the startup delay on Salvator-x is not needed
<kbingham> I love that the startup delay is no longer needed.
<kbingham> (Though very curious how we'll handle that in the full 8 camera
	   case)						        [18:42]
<jmondi> pinchartl: yes, but there might be different failures :) max9271
	 identification, image sensor programming, ISP id reading
<jmondi> currently I got most failures on a single camera, always the same
	 one, so it might as well be HW related
<pinchartl> the startup delay seems *very* fishy. we know there's an MCU that
	    issues I2C transactions. if we open the I2C link over GMSL before
	    the MCU is done, how can this work ?
<jmondi> I tried also reading the MCU content and tried to estimante the delay
	 it takes to startup, which is not documented		        [18:43]
<neg> IIRC the delay was also needed as the boot sequence for H3 ES1.0 setup
      was that the daughterboard should be powerd on after the main board
<jmondi> for 1.5 seconds I cannot access the MCU, but that might be due to the
	 i2c traffic it generates				        [18:44]
<jmondi> I don't know how an 8 seconds delay was estimated in first place
<pinchartl> jmondi: does this mean the delay can be reduced to 1.5s instead of
	    8s, but is still needed ?				        [18:45]
<jmondi> no, I removed delay ocmpletely				        [18:46]
<jmondi> completely
<pinchartl> how is it supposed to work if you start programming the MAX9271
	    while the MCU is also programming it ?
<jmondi> the MCU sends 3 messages to the serializer at startup	        [18:47]
<pinchartl> how do you ensure it doesn't race with the driver programming the
	    MAX9271 ?
<jmondi> the camera gets powered by a gpio hog as soon as the gpio controller
	 is registered						        [18:48]
<jmondi> which happens before we get to open channels one by one
<pinchartl> that sounds like a hack
<jmondi> there's no synchronization, but it doesn't seem worse than an
	 arbitrary delay
<jmondi> rdamc20 is very stable
<jmondi> rdacm21 is less stable
<pinchartl> we'll need to handle power management of cameras	        [18:49]
<pinchartl> keeping them powered on all the time isn't an option
<pinchartl> with a gpio hog we can't control them at runtime
<jmondi> that goes back to the fact we can't control the GPIO that powers the
	 camera with a regulator
<jmondi> due to the circular dependncy
<pinchartl> it's an issue on this platform, yes			        [18:50]
<pinchartl> but there are other GMSL boards where the power to the camera is
	    controlled by a regulator that is actually controllable :-)
<pinchartl> and on some systems, the power to each camera is controllable
	    individually
<jmondi> I think Salvator-X is one of them			        [18:51]
<jmondi> not on out platforms, but I guess it's possible
<pinchartl> not something we have to support right now, but we need to make
	    sure we don't go in a direction that will prevent this from being
	    implemented
<jmondi> ok, I don't think there's anything preventing it from happening
								        [18:53]
<pinchartl> ok
<pinchartl> anything else to discuss ?				        [18:54]
<neg> Not from me
<jmondi> not here
<pinchartl> let's adjourn the meeting then			        [18:55]
<pinchartl> thank you everybody for attending
<pinchartl> have a nice day
<jmondi> thanks
<shimoday> thanks
<neg> Thanks all, have nice day/evening
<shimoday> have a nice day. bye!