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