Merge remote-tracking branch 'gitlab/wiki' into HEAD

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