< pinchartl> welcome to the multimedia group chat meeting < pinchartl> Topic 1. Status Check for the Multimedia Tasks [18:03] < pinchartl> * 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!