diff options
Diffstat (limited to 'wiki/Chat_log/20171109-mm-chatlog')
| -rw-r--r-- | wiki/Chat_log/20171109-mm-chatlog | 212 |
1 files changed, 212 insertions, 0 deletions
diff --git a/wiki/Chat_log/20171109-mm-chatlog b/wiki/Chat_log/20171109-mm-chatlog new file mode 100644 index 0000000..d19b069 --- /dev/null +++ b/wiki/Chat_log/20171109-mm-chatlog @@ -0,0 +1,212 @@ +Multimedia-chat-meeting-2017-11-09 + +10:18 <@pinchartl> so let's start with the multimedia meeting +10:18 <@pinchartl> welcome everybody +10:18 <@pinchartl> (I expect Magnus and Morimoto-san to come back soon) +10:18 <@pinchartl> first topic, status update +10:19 <@pinchartl> Ulrich hasn't sent his status update by e-mail so he should go first, except that he's not here +10:20 <@pinchartl> I expect Magnus to have nothing to report +10:20 < morimoto> pinchartl: I and Magnus is still here. didn't go ;) +10:20 <@pinchartl> morimoto: nice to know :-) +10:20 <@pinchartl> so, for once, I'll start +10:20 <@pinchartl> Since last meeting: +10:20 <@pinchartl> - ELC-E and Linux media summit +10:20 <@pinchartl> - Nearly completed display color keying support for Gen3 +10:20 <@pinchartl> - Started V4L2 lifetime management issues (for VIN Gen3 support) +10:21 <@pinchartl> - Patch review and various discussions +10:21 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +10:21 <@pinchartl> Until next meeting: +10:21 <@pinchartl> - More patch review +10:21 <@pinchartl> - Complete display color keying support for Gen3 +10:21 <@pinchartl> - complete V4L2 lifetime management issues (for VIN Gen3 support) +10:22 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. +10:22 <@pinchartl> Issues and Blockers: +10:22 <@pinchartl> - Patch review and technical discussions are taking too much time +10:22 <@pinchartl> Let's wait two more weeks to see if this is only a transient issue. +10:22 <@pinchartl> that's it for me +10:22 <@pinchartl> next, kbingham[m] +10:23 < kbingham[m]> Not a lot to report from me due to parental leave. But I've received and set up my v3m board +10:24 < kbingham[m]> Not actually booted a kernel yet though. And the other point to note was chasing the async parent patch which seems to be stalled on a branch with sakari +10:25 < kbingham[m]> For next, I expect due to v3m blockages I might be best to look at my vin loopback task first +10:26 <@pinchartl> if you want to still test V3M I think that adding I2C in DT should be fairly easy +10:26 <@pinchartl> assuming pins are muxed by the boot loader +10:26 < kbingham[m]> And I also plan to get the du patches respun as part of base to progress my outstanding patchsets. +10:26 <@pinchartl> if you need to deal with PFC, then don't bother for now +10:26 < kbingham[m]> Ok great +10:26 < kbingham[m]> If it's easy l have a go +10:26 < kbingham[m]> Sorry. Mobile device ... I'll have a go :-) +10:27 < kbingham[m]> Eot :-) +10:27 <@pinchartl> thank you +10:27 <@pinchartl> next, neg +10:27 < neg> A) +10:27 < neg> - [PATCH] media: v4l: async: fix unregister for implicitly registered sub-device notifier +10:27 < neg> - Made next version of both rcar-vin and rcar-csi2 ready but not posted, waiting private review from Laurent before posting. +10:27 < neg> - Attended ELCE and Multimedia summit (Thursday and Friday). +10:27 < neg> B) +10:27 < neg> - Post both series for VIN and CSI-2 +10:27 < neg> - See if I can get VIN to work on V3M +10:27 < neg> C) +10:28 < neg> - I want to post VIN patches latest on Friday so if there is to be a private review before I post them publicly please do so soon :-) +10:28 < neg> - Not sure about status of Laurents 'V4L2 lifetime management issues (for VIN Gen3 support)'. Should I post the VIN series without this fix in the framework? +10:28 < neg> --EOT and copy-paste errors-- +10:28 <@pinchartl> Friday might be a bit of a hard deadline for me but I'll do my best +10:28 <@pinchartl> regarding the V4L2 lifetime management issues, just mention that I'm working on it +10:29 < neg> OK, no worries if you don't have time before Friday, are you OK with me posting them to ML anyhow? +10:29 <@pinchartl> yes it is +10:30 < neg> I'm happy to learn you are working on the lifetime management issues :-) Do you think it's worthwile to try and upstream that work and VIN Gen3 in parallel or should the VIN work depend on it? +10:31 <@pinchartl> I don't think the VIN work should really depend on it, it's quite independent +10:32 < neg> OK, then I won't refere to it in the cover letter :-) Thanks for clearing that up for me +10:32 <@pinchartl> you're welcome +10:32 <@pinchartl> next, jmondi2 +10:33 <@pinchartl> (I wonder what happened to jmondi1) +10:33 < jmondi2> pinchartl, I cannot access my VPS this morning where irssi is running +10:33 < jmondi2> so here I am as jmondi2 on xchat +10:33 < jmondi2> btw +10:34 < jmondi2> A) +10:34 < jmondi2> - CEU driver multiplanar API support, data fetch, image capture support on Gr-Peach +10:34 < jmondi2> - Resumed development on Migo-R +10:34 < jmondi2> -- fought with memory issues +10:34 < jmondi2> -- [PATCH] sh: defconfig: Remove NUMA support from Migo-R +10:35 < jmondi2> -- [PATCH] sh: migor: Reserve memory block for CEU +10:35 < jmondi2> -- fought with userspace issues (due to FPU) +10:35 < jmondi2> -- Implemented platfrom data parsing for Migo-R on CEU driver +10:35 < jmondi2> -- Moved sensor drivers away from soc_camera +10:35 < jmondi2> B) +10:36 < jmondi2> - Submit CEU driver to linux-media +10:36 < jmondi2> - Document on elinux.org GR-Peach setup used to develop CEU +10:36 < jmondi2> - Submit to linux-sh Migo-R platform patches to use new CEU driver +10:36 < jmondi2> - Get rid of soc_camera framework from Linux! +10:36 < jmondi2> C) +10:36 < jmondi2> - Issues with CEU HW block enablement on Migo-R (all writes/reads are 0 on the IP Block) +10:37 < jmondi2> - There are more platforms using CEU in arch/sh.. we should port all of them before removing the original driver +10:37 < jmondi2> (and I wonder how we can test them) +10:37 < jmondi2> -- oet +10:37 < jmondi2> --eot +10:37 <@pinchartl> thank you +10:37 <@pinchartl> no need to test them, you can blindly port them +10:37 < jmondi2> love it! +10:37 <@pinchartl> if they compile, that's enough +10:38 < jmondi2> (love it)^2 +10:39 <@pinchartl> :-) +10:39 < jmondi2> I'm a bit worried about the well known low responsivness of sh maintainers, so I won't hold CEU driver integration in linux-media to wait for the SH part +10:39 <@pinchartl> regarding the soc_camera framework +10:39 <@pinchartl> the pxa-camera driver uses it :-( +10:39 <@pinchartl> even if it's in drivers/media/platform/ +10:39 <@pinchartl> Hans said he would handle that +10:39 < jmondi2> doh :( +10:40 <@pinchartl> yes, that was my reaction too +10:40 <@pinchartl> at least without sh_mobile_ceu in the way, Hans will have a bigger incentive to tackle pxa-camera +10:40 < jmondi2> for sure! +10:41 <@pinchartl> thank you for your report +10:41 <@pinchartl> next, morimoto +10:41 < morimoto> ok +10:41 < morimoto> A) What have I done since last time +10:41 < morimoto> Re-send ALSA SoC cleanup patches. 1 month pasted It is very big patch-set, so, I subdivided these "prepare" part into 6 small-patch-sets. Now, 2/6 steps. +10:41 < morimoto> Working with BSP team about sound issue which was pointed from Customer +10:41 < morimoto> B) What I plan to do till next time +10:41 < morimoto> Continue posting patches for ALSA SoC cleanup +10:41 < morimoto> C) Problems I have currently +10:41 < morimoto> None +10:41 < morimoto> --EOF-- +10:42 <@pinchartl> I'm happy to know you have no problem ! +10:42 < morimoto> Oops, I have TCR vs TCRV problem ;P +10:42 <@pinchartl> that's not for multimedia :-) +10:42 < morimoto> s/TCRV/TCRB/ +10:43 < morimoto> but it is related to sound noise :P +10:43 <@pinchartl> indeed +10:43 <@pinchartl> but the problem is in SCIF ;-) +10:43 < morimoto> Yes +10:43 <@pinchartl> anyway, let's see what will happen with the DE bit +10:43 <@pinchartl> thank you for your report +10:43 <@pinchartl> dammsan: anything to add to the usual "N/A" report this time ? :-) +10:44 < morimoto> dammsan said no +10:45 <@pinchartl> could you ask Dammsan whether there's a chance Kieran and I could get an SoW signed before the deadline ? +10:45 <@pinchartl> (I mean the 11/M deadline) +10:46 < morimoto> dammsan said that he already submitted it to Jinso today +10:47 <@pinchartl> \o/ +10:47 <@pinchartl> thank you +10:47 <@pinchartl> that's it for the status updates +10:47 <@pinchartl> topic 2, next meeting +10:47 <@pinchartl> I assume that will be two weeks from now at the same time ? +10:48 < morimoto> pinchartl: I posted request mail for MultiPeria +10:48 < morimoto> Of course, we can discuss it on mail +10:48 <@pinchartl> morimoto: do you mean for the code camp after the FOSDEM ? +10:48 < morimoto> code camp ?? +10:48 <@pinchartl> geertu: does that work for you? +10:48 < morimoto> BSP team request +10:49 <@pinchartl> morimoto: ah that +10:49 <@pinchartl> yes, I've replied +10:49 < morimoto> Sorry for our noise +10:49 <@pinchartl> don't worry +10:49 < morimoto> For neg about rvin_write(vin, 0, VNMC_REG). He already accepted this request. Thank you neg. +10:50 < morimoto> about ADV7511W(HDMI out) and ADV7612(HDMI in) address conflict on D3. +10:50 < morimoto> I don't know who can handle it +10:50 <@pinchartl> address conflict ? have you sent an e-mail about that ? +10:50 < morimoto> and, DU-VSPD connection request +10:52 < morimoto> Yes, address conflict +10:52 < morimoto> Subject: Re: [periperi] 2017-11-09 - Group meeting - Infos & Call for updates +10:52 < morimoto> Date: Tue, 07 Nov 2017 09:57:28 +0900 +10:52 < morimoto> 2nd topic on it +10:53 <@pinchartl> found it, thanks +10:54 <@pinchartl> so there are two chips at the same address +10:54 <@pinchartl> lovely +10:54 < morimoto> orz +10:54 <@pinchartl> could we get the Draak schematics ? +10:54 < morimoto> I think wiki already have it ? +10:54 <@pinchartl> good point :-) +10:55 <@pinchartl> let me check +10:57 <@pinchartl> and how are we supposed to handle that ? +10:57 < morimoto> This is not urgent. But can MultiPeria handle it somehow. maybe next or more next SoW ? +11:00 <@pinchartl> ah, it's about the secondary addresses, not the main address ? +11:01 < morimoto> They said that "But if it uses 0x72 (On Draak), it is same as ADV7612," +11:01 <@pinchartl> no, I'm not sure to see where the problem is +11:01 <@pinchartl> the ADV7612 uses 0x98 or 0x9A for its default address +11:01 < geertu> Ah, there's a secondary address, not mentioned in the schematics? +11:02 < geertu> pinchartl: Meeting in two weeks, or code camp after FOSDEM? +11:02 < geertu> Meeting in two weeks is OK for me +11:02 <@pinchartl> geertu: meeting in two weeks +11:03 <@pinchartl> the code camp is only for mutlimedia +11:03 <@pinchartl> and multimedia too of course +11:03 < geertu> I don't know mutlimedia, but I have a great fantasy about muttimedia ;-) +11:03 < morimoto> In ADV7511W, it has I2C_PACKET register +11:04 < morimoto> this address and ADV7612's HDMI slave address will be conflict, they said +11:05 < morimoto> I noticed that we have more detail info about this. +11:05 < morimoto> I will report it on mail +11:05 <@pinchartl> yes, it will conflict with ADV76XX_PAGE_HDMI +11:05 <@pinchartl> OK, we can handle that +11:05 < morimoto> Thanks. I will post more detail info about that +11:06 <@pinchartl> any other discussion topic ? +11:06 < morimoto> DU-VSPD connection +11:06 < morimoto> Our side opinion is that DT is very OK. +11:08 <@pinchartl> yes, but I don't think it is +11:08 <@pinchartl> it's not a hardware description, it's a particular use case +11:08 <@pinchartl> so we need another way +11:09 < morimoto> DU and VSPD connection are not hardware description ? +11:10 <@pinchartl> VSPD0 is connected to the input of DU's channels 0 and 3, VSPD1 to the input of DU's channel 1 and VSPD2 to the input of DU's channel 2 +11:10 <@pinchartl> that's a hardware description, and that's what we have in DT +11:11 <@pinchartl> now, how to route the DU inputs to the superposition processors inside the DU is not a hardware description, it's a configuration +11:11 <@pinchartl> the input of DU's channel 0 is routed by default to superposition processor 0 +11:11 <@pinchartl> and the input of DU's channel 1 is routed by default to superposition processor 1 +11:11 <@pinchartl> the DU has the ability to route the input of DU's channel 0 to superposition processor 1 +11:11 <@pinchartl> it's internal to the DU and selectable at runtime +11:13 <@pinchartl> the superposition processor 0 can even blend the input of DU's channel 0 and DU's channel 1 +11:14 <@pinchartl> luckily it seems we don't need this feature for now +11:14 <@pinchartl> (and hopefully never) +11:15 <@pinchartl> I'd like to know more about the use case and why the customer wants to connect VSPD1 to DU0 +11:15 < morimoto> Can you check +11:15 < morimoto> Subject: Re: [periperi] How to connect VSPD0 to DU1? +11:15 < morimoto> +11:15 < morimoto> Date: Wed, 8 Nov 2017 00:48:29 +0000 +11:15 < morimoto> +11:15 <@pinchartl> yes, I'll reply to the last e-mail +11:16 < morimoto> OK, thanks +11:16 <@pinchartl> any other general discussion topic ? +11:17 < morimoto> nothing from me. thanks +11:17 < neg> not from me, I'm happy :-) +11:17 <@pinchartl> jmondi2: are you happy too ? +11:17 <@pinchartl> and kbingham[m] ? +11:18 < jmondi2> pinchartl: nothing from here! +11:18 < kbingham[m]> I'm happy. +11:19 < kbingham[m]> Covered in baby pee. But sure. Happy :-) +11:19 <@pinchartl> if it's all rainbows and unicorns, then let's close this meeting +11:19 <@pinchartl> thank you all for attending |