wiki: Add M/M chatlog for 2021-02-18

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 324 insertions, 0 deletions

diff --git a/wiki/Chat_log/20210218-mm-chatlog b/wiki/Chat_log/20210218-mm-chatlog
new file mode 100644
index 0000000..92cbfc8
--- /dev/null
+++ b/wiki/Chat_log/20210218-mm-chatlog
@@ -0,0 +1,324 @@
+<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!