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 !