path: root/wiki/Chat_log/20171109-mm-chatlog

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