diff options
Diffstat (limited to 'wiki/Chat_log/20210218-mm-chatlog')
| -rw-r--r-- | wiki/Chat_log/20210218-mm-chatlog | 324 |
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! |