diff options
Diffstat (limited to 'wiki/Chat_log/20180920-mm-chatlog')
| -rw-r--r-- | wiki/Chat_log/20180920-mm-chatlog | 281 |
1 files changed, 281 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180920-mm-chatlog b/wiki/Chat_log/20180920-mm-chatlog new file mode 100644 index 0000000..00c88ea --- /dev/null +++ b/wiki/Chat_log/20180920-mm-chatlog @@ -0,0 +1,281 @@ +Multimedia-chat-meeting-2018-09-20 + +10:22 < pinchartl> welcome to the multimedia meeting +10:22 < pinchartl> topic 1, status updates +10:23 < pinchartl> * Jacopo +10:23 < pinchartl> Since last meeting: +10:23 < pinchartl> - R8A77990 (E3) VIN and CSI-2 +10:23 < pinchartl> Respined Ebisu support patch, supported Laurent and Niklas in testing. +10:23 < pinchartl> - Respined the adv748x single endpoint probe patches +10:23 < pinchartl> - Reviewed and tested Sakari's v4l2-fwnode patches +10:23 < pinchartl> - Ported CEU driver to use new fwnode defaults +10:23 < pinchartl> - Tested and reviewed the D3/E3 LDS PLL patches +10:23 < pinchartl> Until next meeting: +10:23 < pinchartl> - Really look into the E3 CSI-2 issue +10:23 < pinchartl> - Test niklas v4l2-mux series +10:23 < pinchartl> - Have adv748x patches merged +10:23 < pinchartl> Issues and Blockers: None +10:23 < pinchartl> jmondi: any comment ? +10:23 < jmondi> pinchartl: not really +10:23 < jmondi> apart deciding how to procede forward with E3 VIN and CSi-2 testing +10:24 < jmondi> but that's for later, with you and neg +10:24 < pinchartl> I plan to test the next version of the adv748x patch +10:25 < jmondi> pinchartl: great, let's sync so I can support +10:25 < pinchartl> in the meantime, if there are CSI-2 and VIN debug registers that could help diagnosing the problem, it would be nice to have a small hack debug patch to read them +10:26 < pinchartl> * Kieran +10:26 < pinchartl> Since last meeting: +10:26 < pinchartl> - VSP1 and DU patch respins and posting +10:26 < pinchartl> - Testing D3/E3 LVDS patch series +10:26 < pinchartl> - Discovered and investigated rcar-du Alpha Blending bug. +10:26 < pinchartl> - ADV748x development and reviews +10:26 < pinchartl> - periupport updates for bsp370/v4.14 +10:26 < pinchartl> - Posted patches to fix the alpha blend regression +10:26 < pinchartl> - Conference planning +10:26 < pinchartl> Until next meeting: +10:26 < pinchartl> - M3-N Rotation bug needs investigation. +10:26 < pinchartl> - Writeback rebase and repost. +10:26 < pinchartl> - Partition phase work +10:26 < pinchartl> - ADV748x dynamic routing. +10:26 < pinchartl> Issues and blockers: None +10:26 < pinchartl> kbingham: any comment ? +10:26 < jmondi> pinchartl: not sure where we have to look into, my guesses are now adv748x 2 lanes config (you have to test if I got it right) and the CSI-2 interface VC configuration +10:26 < jmondi> sorry +10:26 < kbingham> Only one for morimoto-san +10:26 < kbingham> morimoto, Do we need to submit cost plans for ELCE? +10:27 < morimoto> Yes, please +10:27 < kbingham> morimoto, Ack. I'll send an email this morning :) +10:27 < kbingham> Otherwise good here. +10:27 < morimoto> and, Hotel cost, too +10:28 < kbingham> Sure +10:28 < kbingham> Me Laurent and Jacopo will share accomodation I believe +10:28 < pinchartl> jmondi: I don't know where the problem is, so I can't tell you what to look into either :-) +10:29 < jmondi> pinchartl: I understand, but it's hard to pick a register to help debug, if we don't know where the problem is :) anyway, let's sync and try +10:30 < pinchartl> * Laurent +10:30 < pinchartl> Until next meeting: +10:30 < pinchartl> - More patch review +10:30 < pinchartl> - D3/E3 DU LVDS PLL upstreaming +10:30 < pinchartl> - Attend XDC (X Developers Conference) next week +10:30 < pinchartl> Since last meeting: +10:30 < pinchartl> - More patch review +10:30 < pinchartl> - D3/E3 DU LVDS PLL upstreaming +10:30 < pinchartl> - Get GMSL patches merged +10:30 < pinchartl> Issues and blockers: None +10:30 < pinchartl> any question ? +10:31 < jmondi> what about GMSL? +10:31 < jmondi> just respin the series? +10:31 < jmondi> or you need support for that? +10:32 < pinchartl> I need to finish the review, and then send a pull request +10:32 < pinchartl> or one of you could send the pull request, no issue with that +10:33 < pinchartl> * Morimoto-san +10:33 < pinchartl> Since last meeting: +10:33 < pinchartl> - TDM investigations (???) +10:33 < pinchartl> Until next meeting: +10:33 < pinchartl> - Implement TDM expand mode using StarterKit + KingFisher +10:33 < pinchartl> Issues and Blockers: +10:33 < pinchartl> - We can't check TDM split mode +10:33 < pinchartl> morimoto: any comment ? +10:33 < morimoto> no, thanks +10:34 < pinchartl> * Niklas +10:34 < pinchartl> Since last meeting: +10:34 < pinchartl> - [PATCH] v4l2-common: fix typo in documentation for v4l_bound_align_image() +10:34 < pinchartl> - [PATCH 0/3] rcar-vin: add support for UDS (Up Down Scaler) +10:34 < pinchartl> - [PATCH 0/3] i2c: adv748x: add support for CSI-2 TXA to work in 1-, 2- +10:34 < pinchartl> and 4-lane mod +10:34 < pinchartl> Until next meeting: +10:34 < pinchartl> - Work on review comments to UDS and adv748x +10:34 < pinchartl> - Pray for feedback to the multiplexed streams patch-set +10:34 < pinchartl> Issues and blockers: None +10:35 < pinchartl> neg: any comment ? +10:35 < neg> no comment, thanks +10:35 < pinchartl> prayers seem not to have worked well, could you try to push me a bit more explicitly to get the muxed streams series reviewed ? +10:36 < kbingham> morimoto, What is TDM investigations ? +10:36 < neg> will do :-) +10:36 < kbingham> Is that an audio thing ? +10:36 < morimoto> kbingham: yes. there are 3 type of format +10:36 < morimoto> TDM x 2, and Mono +10:37 < morimoto> I did was Mono, not TDM. sorry pinchartl +10:37 < morimoto> --eol-- +10:38 < pinchartl> thanks, I'll update that +10:38 < pinchartl> * Simon (Kaneko-san) +10:38 < pinchartl> Since last meeting: +10:38 < pinchartl> - Merged: [PATCH v2] ASoC: rsnd: Add device tree binding for r8a77990 +10:38 < pinchartl> Until next meeting: +10:38 < pinchartl> - Testing M3-N and E3 Audio support +10:38 < pinchartl> Issues and blockers: None +10:38 < pinchartl> horms: any comment ? +10:39 < horms> Not that I need to find time to actually do the testing +10:39 < horms> Not other than that... +10:40 < pinchartl> * Ulrich +10:40 < pinchartl> Since last meeting: None +10:40 < pinchartl> - Reviewed (half of) "R-Car D3/E3 display support (with LVDS PLL)" +10:40 < pinchartl> Until next meeting: TBD +10:40 < pinchartl> Issues and blockers: None +10:40 < pinchartl> uli___: any comment ? +10:41 < uli___> i'll be afk until tuesday, will it still be ok to review the back half of the d3/e3 hdmi series then? +10:41 < horms> possibly related: I plan to close the reneas tree for v4.20 next Wednesday +10:42 < pinchartl> uli___: sure +10:42 < pinchartl> horms: ok +10:42 < uli___> ok. no other comments. +10:42 < pinchartl> the DT bindings have been approved, can I then send the DT changes for v4.20 ? +10:44 < pinchartl> horms: that was a question for you :-) +10:45 < horms> If they have been approved and you think the DT changes are finalised, then yes, feel free. +10:45 < pinchartl> thanks +10:45 < pinchartl> that's it for the status updates +10:45 < pinchartl> topic 2, additional tasks for Q4 +10:46 < pinchartl> damm: do you have any comment on that before we start ? +10:47 < damm> nope +10:47 * morimoto I believe I can get some answer about 3 questions +10:47 * morimoto in later +10:48 < pinchartl> morimoto: I've seen them, we'll get to that, don't worry :-) +10:48 < pinchartl> so regarding additional tasks for Q4 +10:48 < morimoto> thanks +10:48 < pinchartl> we have reduced budget +10:48 < pinchartl> which implies reduced additional tasks +10:49 < pinchartl> with 10 days per quarter I don't see how we can reasonably include upstreaming in any additional task anymore +10:49 < pinchartl> damm: I would thus like to know what type of tasks Renesas will expect now +10:49 < pinchartl> they just can't include everything from development to upstreaming anymore +10:50 < pinchartl> upstreaming will need to be handled under base time +10:50 < damm> pinchartl: yes i agree +10:51 < jmondi> which makes, depending on how much time one has left, only one task in total for q4 per person acceptable +10:51 < pinchartl> jmondi: I would go for one task per quarter, yes +10:51 < jmondi> as it will consume additional time for implementation and all base time for upstreaming +10:52 < jmondi> pinchartl: yeah, my point is that also base time will be affected, leaving not much time for the usual base tasks (review, backlog, etc) +10:53 < jmondi> but I think this a well known issue... +10:53 < pinchartl> it should be known at least +10:53 < pinchartl> it's certainly known on our side that less time means less output :-) +10:54 < pinchartl> damm: you explained before that Renesas expected upstreaming to be included in additional tasks. now that this can't be done anymore, what type of tasks would be acceptable ? +10:58 < damm> prototypes, minor bug fixes, building some hardware rig to extend testing etc +10:58 < pinchartl> ok, thanks +10:58 < damm> makign test programs +10:58 < damm> or extending them +10:58 < pinchartl> so we need to come up with additional tasks +10:58 < damm> that's my take at least +10:58 < pinchartl> I would like all multimedia developers to submit proposals +10:59 < pinchartl> you can reply to the meeting report e-mail, or we can discuss them now if you already have ideas +10:59 < kbingham> pinchartl, I'd probably consider the M3-N Rotation bug as a candidate then +11:00 < jmondi> there are a few things around adv748x but I'm not sure how to assign them +11:00 < neg> I would love to work on improving test rigs but is that not a dangerus path to prove the value of the upstream team? +11:00 < neg> Would it not be a bit more clever to package a set of IP specific upport commits as add tasks? +11:01 < pinchartl> neg: my understanding is that upport as an additional task was frowned upon by Renesas, but things might have changed +11:02 < neg> pinchartl: ahh I see was not aware of that scrap that then :-) +11:02 < damm> actually +11:02 < damm> i don't mind including the up-port bit +11:02 < damm> if it is something that can be defined clearly and is in demand +11:02 < pinchartl> damm: that's good to hear :-) +11:02 < damm> also about test rig +11:03 < damm> if we can document how things may be done in a public space then i think it has value by itself +11:04 < damm> (this is how we automate eject/insert of SD cards for example) +11:04 < kbingham> There is an automated-testing mailinglist (I think started by Tim Bird) where lots of farming talks are currently occuring in public space. +11:04 < kbingham> And a test-summit at ELCE +11:04 < kbingham> geertu, Are you attendign that test summit? +11:04 < pinchartl> the testing summit will occur at the same time as the V4L2 summit I believe :-( +11:05 < geertu> kbingham: yes I will. Will mostly be about the automated testing part, I believe +11:05 < kbingham> geertu, I'm sure that's what we need more of :) +11:06 < geertu> pinchartl: Yes, -ETOOMANYCONCURRENCY +11:06 < pinchartl> geertu: something like that +11:06 < geertu> kbingham: Not if it involves Jenkins +11:06 < kbingham> geertu, Is that their only solution ? :S +11:08 < pinchartl> let's move to the next topic +11:08 < pinchartl> morimoto: you had questions +11:08 < morimoto> yeah +11:08 < pinchartl> I've just replied to them by e-mail +11:08 < pinchartl> I'll paste my replies here +11:08 < morimoto> I got answer from kbingham and jacopo +11:09 < neg> kbingham: well is not gerrit + jenkins the silver bullet solution to all software quality and assurence it be devliverd on time? +11:09 < morimoto> thanks ! I got your answer +11:09 < pinchartl> ah, there are other answers too +11:10 < pinchartl> regarding the VSP 1x1 image size, Mauro has applied to the patch to this tree +11:10 < pinchartl> s/this tree/his tree/ +11:11 < kbingham> Oh - I missed that :) +11:11 < kbingham> But great :) +11:11 < pinchartl> for the DU reserved registers, Jacopo has submitted patches +11:12 < pinchartl> but I'm concerned about all the changes that are requested to match the datasheet to the last detail, when there's no clear indication that this is needed +11:13 < pinchartl> I can consider merging Jacopo's series this time, but next time we'll get a request along the lines of "the datasheets states this order of operations, the driver need to match" I will request a proof that the current implementation causes a real bug +11:14 < wsa> damm: about remote inserting SD cards: I got a device from Pengutronix which does that +11:14 < pinchartl> and regarding the D3/E3 LVDS PLL and clock issue, I plan to submit that as an additional task for Q4 +11:14 < pinchartl> morimoto: does this answer your questions ? +11:14 < damm> wsa: great! i recall linaro had something like that too +11:14 < jmondi> pinchartl: awmm (I don't know how to properly express demotivating feelings with onomatopoeic expressions in English, hope it's clear) +11:15 < pinchartl> jmondi: it's not a judgment on the quality of your work, but I think that several requests we have received are pointless to start with +11:15 < wsa> damm: https://www.pengutronix.de/2017-10-23-usb-sd-mux-automated-sd-card-juggler.html +11:15 < pinchartl> and I don't want to continue increasing the complexity of an already complex piece of code when there's no need to +11:15 < morimoto> pinchartl: sorry my late response. Thanks, nice answer +11:15 < damm> pinchartl: since many devices are shared IP that should work on many SoCs it would make sense to give feedback to renesas to make sure the register read/write order is consistent across products +11:16 < morimoto> I will forward these to BSP team +11:16 < jmondi> pinchartl: sure I get it, I was referring to this kind of requests +11:16 < pinchartl> damm: it's not just about consistency between products, it's also that in many cases a specific write order is not required +11:17 < pinchartl> if you have to program lots of registers before starting the hardwarer +11:17 < pinchartl> more often than not the order doesn't matter +11:17 < damm> lets just say that i agree with you very much +11:17 < wsa> I could ask if they can bring some to ELCE if that helps. I can bring the one I have, too +11:17 < pinchartl> and mandating a specific order sometimes creates extra complexity in the driver by breaking the natural grouping of parameters we get from existing APIs +11:18 < damm> i'm with you +11:18 < pinchartl> thanks :-) +11:18 < damm> that kind of request makes the "alpabetize the headers" thing look good +11:18 < morimoto> pinchartl: sometimes (anytimes ?) BSP team cares very picky point +11:19 < pinchartl> damm: :-D +11:19 < pinchartl> morimoto: in many cases they have good points, they point us to small bugs that are hard to find or only happen in some corner cases, but that are bugs nevertheless, and I'm happy to fix them +11:20 < pinchartl> but sometimes it really feels like they have been asked to do something and they push the request down to us, even if the request wasn't very sensible to start with +11:20 < damm> if there are dependenices and ordering between several IPs it would be helpful to know those ahead of time +11:20 < morimoto> one reason is that it is related to customer +11:21 < morimoto> customer is checking "datasheet" and "driver" +11:21 < pinchartl> morimoto: then I think the datasheet should be updated +11:21 < pinchartl> as that's where the problem is +11:21 < morimoto> and ask to us "why datasheet and driver are not same ?" if driver and datasheet are mismatched +11:21 < pinchartl> if the hardware can work with multiple orders +11:21 < pinchartl> and the datasheet says that a specific order is required +11:21 < pinchartl> then the datasheet is wrong :-) +11:22 < damm> the data sheet is like a recommendation +11:22 < damm> it is more like fiction than fact +11:22 < morimoto> yeah, sometimes multiple order is OK. but it is case-by-case +11:23 < morimoto> This is unfortunately complex area to solve +11:23 < pinchartl> of course when some operations have to be ordered a certain way, and the driver doesn't follow that, we should fix the code +11:23 < damm> morimoto: but changing order requirement late in the process seems not very useful +11:23 < morimoto> HW team vs datasheet team vs softweare team vs customer +11:23 < pinchartl> one problem with the datasheet documenting a particular order without stating whether it's mandatory or not, +11:24 < damm> morimoto: if this was a requirement then we want to know this from day 0 +11:24 < pinchartl> is that important information get lost in the noise +11:24 < pinchartl> as it then becomes easy to read the datasheet and think that it's just the usual case of a recommended order +11:24 < pinchartl> while it's actually super important +11:25 < pinchartl> so by saying that things are mandatory all around when they are not, the real mandatory ones don't clearly show +11:25 < pinchartl> but I don't think there's any fundamental disagreement among us here +11:25 < pinchartl> any other discussion topic ? +11:26 < damm> pinchartl: maybe we can implement some hardware abstraction layer and use the drivers from Integrity(tm) that follow the correct order(tm) +11:26 < morimoto> This kind of topic is unfortunately difficult to solve. I will ask to BSP team whether it is very important, or datasheet side can updated or so. +11:27 < damm> my opinion is that shared IP needs to be discussed on a broader scale +11:27 < damm> renesas needs to learn how to manage shared ip +11:28 < damm> i expect you guys to help out that process by good feedback =) +11:28 < damm> no other topic from me +11:28 < morimoto> I think this is not only Renesas issue. Many people are related to this kind of topic, but no one knows who has correct answer... +11:28 < morimoto> no topic from me, too +11:29 < jmondi> nothing to add from my side neither +11:29 < pinchartl> alright +11:29 < pinchartl> last topic then +11:29 < pinchartl> next meeting +11:29 < pinchartl> two weeks from now, on October the 4th, same time as usual ? +11:30 < kbingham> Aribtrary question from me - Has Gen4 hardware been started already ? +11:30 < morimoto> kbingham: not yet +11:30 < kbingham> ( I assume they start gen4 before Gen3 ships) +11:30 < kbingham> Oh ok - so my assumption is wrong ;) +11:30 < morimoto> it is depend on what is your "start" mean +11:31 < morimoto> "Gen4 plan" is started, "Gen4 implement" is not yet +11:31 < kbingham> :) +11:32 < kbingham> So it's 18-24 months at least or more before any g4 hardware appears then :) +11:32 < morimoto> But we will have Gen3.5 :) +11:32 < kbingham> Oh :) +11:32 < morimoto> I don't know detail, thought +11:32 < neg> Gen3.5 = new ES versions ? +11:33 < morimoto> neg: I don't know, sorry +11:33 < geertu> s/arm/risc-v/? +11:33 < neg> morimoto: no worries just curious :-) +11:33 < morimoto> geertu: not Risc-V :) +11:34 < kbingham> pinchartl, Oct 4th sounds good to me. +11:34 < morimoto> Oct 4th is OK to me +11:35 < pinchartl> that's all I have for today +11:35 < neg> 4th OK for me +11:35 < pinchartl> I propose adjourning the meeting +11:35 < pinchartl> does anyone second ? +11:36 < jmondi> fine wiht me +11:36 < neg> seconded, thanks for hosting the meeting +11:36 < morimoto> 2nd +11:36 < pinchartl> meeting adjourned, thank you all for attending, and have a nice day ! |