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

1 files changed, 142 insertions, 0 deletions

diff --git a/wiki/Chat_log/20171019-mm-chatlog b/wiki/Chat_log/20171019-mm-chatlog
new file mode 100644
index 0000000..9d45391
--- /dev/null
+++ b/wiki/Chat_log/20171019-mm-chatlog
@@ -0,0 +1,142 @@
+Multimedia-chat-meeting-2017-10-19
+
+10:11 < pinchartl> thank you. let's get started with multimedia then
+10:11 < pinchartl> let's see who's here
+10:11 < pinchartl> we have jmondi 
+10:11 < pinchartl> dammsan: 
+10:11 < pinchartl> morimoto: 
+10:11 < pinchartl> neg: 
+10:11 < pinchartl> uli__: 
+10:11 < pinchartl> and possibly kbingham_ lurking
+10:11 < wsa_> i gotta run, cya guys!
+10:12 < pinchartl> first topic, status check for multimedia tasks
+10:12 < pinchartl> jmondi: you reported last, please start :-)
+10:12 < jmondi> Marex: why are you jumping between this and #renesas-soc room? Split personality as headless suggested? :)
+10:12 < jmondi> sure
+10:12 < pinchartl> (next will be uli__, neg, kbingham_, morimoto)
+10:13 < jmondi> first max9286: I have re-based an old patch series on Kieran's stabilization one and submitted a new one to decide at run-time if we want to run in single source mode or not
+10:14 < jmondi> also, I began testing OV10635 settings based on what OV suggested, anyway the information we received are incomplete (that should be a C)
+10:15 < jmondi> on CEU I have implemented data synch fetch mode support as that's the one according to Chris, that people is mostly interested on, and debugged the driver format handling on Peach
+10:16 < jmondi> unfortunately I see spurious VSYNC interrupts (and get VBS interrupts from CEU consequentially, for the interested readers) and I don't know if I want to blame, sensor driver or my driver
+10:16 < jmondi> I have tried replacing mainline driver for ov7670 with the very simple one Chris provided me, but same results, so...
+10:16 < jmondi> B is continue development of CEU on Migo-R and keep trying debugging GMSL setup
+10:17 < jmondi> (I really would love to see what happens on the camera side of GSML setup, but we're struggling to attach probes there apparently)
+10:17 < jmondi> --eot--
+10:18 < pinchartl> and C ?
+10:18 < jmondi> pinchartl: correct
+10:18 < jmondi> OV people has not provided complete answers, I need Migo-R access from remote as Peach in unreliable
+10:19 < jmondi> that is --eot--
+10:19 < pinchartl> thank you
+10:19 < pinchartl> next, uli__ 
+10:19 < uli__> i sent a new revision of the chromebook r13 support, with much fewer hacks
+10:20 < uli__> it still has the mmsys hack, but discussions on how to solve that are underway
+10:20 < uli__> next i'll start with porting the gpu driver
+10:20 < morimoto> pinchartl: I need to go back home soon. Can I be next guys ? Sorry for my noise
+10:20 < uli__> that's it from me
+10:21 < pinchartl> thanks
+10:21 < pinchartl> morimoto: sure, please go ahead
+10:21 < morimoto> Thanks
+10:21 < morimoto> A) What have I done since last time
+10:21 < morimoto> I pinged to OmniVision guy this morning
+10:21 < morimoto> I and ALSA maintainer worked for Hot-Unplug support. We needed to consider ALSA / ALSA SoC framework. but it OK now. ALSA framework patch will be added v4.15, ALSA SoC will be v4.16
+10:21 < morimoto> BSP team noticed sound noise issue for Capture. the issue was on DMAC (= TCR vs TCRB). I posted this patch. latest is v3.
+10:21 < morimoto> virtual machine (= integrity) team noticed latest BSP can't output sound on VM. I'm supporting them now.
+10:22 < morimoto> B) What I plan to do till next time
+10:22 < morimoto> re-post DMAC patch v3 or more ?
+10:22 < morimoto> continue posting ALSA SoC cleanup patch witch is needed for next generation ALSA SoC system.
+10:22 < morimoto> C) Problems I have currently
+10:22 < morimoto> Very slow progress for ALSA SoC cleanup
+10:22 < morimoto> --EOL--
+10:22 < pinchartl> arigatō gozaimasu
+10:22 < pinchartl> next, dammsan 
+10:23 < dammsan> nothing to report here
+10:23 < pinchartl> I had already prefilled the report with that information ;-)
+10:23 < pinchartl> next, kbingham_, who is likely away
+10:23 < pinchartl> Since last meeting:
+10:23 < pinchartl> - Continued on probe stabilization investigation
+10:23 < pinchartl> - Exposed I2C bus on Breakout camera
+10:23 < pinchartl> - Lots of trace and analysis of boot time, and power up of RDACM20
+10:23 < pinchartl> - Patches posted, and a better understanding of the early stages of camera 
+10:23 < pinchartl> probing all round
+10:24 < pinchartl> For the next two weeks:
+10:24 < pinchartl> - V3M board is en-route, so that will likely be the next task
+10:24 < pinchartl> However, Kieran's availability will be low for the next couple of weeks.
+10:24 < pinchartl> Issues and Blockers: None
+10:24 < pinchartl> next, neg 
+10:24 < neg> Multimedia)
+10:24 < neg> A)
+10:24 < neg>     - [PATCH] v4l: rdacm20: add delay after configuring data mode and rate
+10:24 < neg>     - [PATCH] v4l: rdacm20: add log_status operation
+10:24 < neg>     - Register investigations of the MAX9271 of "normal" and "troubled" cameras.
+10:24 < neg>     - Accepted that my 8-camera extension board is half broken and only MAX9286_B is functional :-(
+10:24 < neg>     - Started (hopefully) last rework of VIN Gen3 patches.
+10:24 < neg> B)
+10:24 < neg>     - Rebase multiplexed pads on Sakari's patch series.
+10:24 < neg>     - Attend multimedia core dev meeting after ELCE together with Laurent.
+10:24 < neg>     - If V3M arrives, add support for it in the VIN Gen3 driver and DT.
+10:24 < neg> C)
+10:24 < neg>     - Not sure about status of Laurents 'V4L2 lifetime management issues
+10:24 < neg>       (for VIN Gen3 support)' work which will be needed before I can
+10:24 < neg>       post the (hopefully) last version of VIN Gen3 support. I only
+10:24 < neg>       bring it up here as I'm about to sign an additional contract for
+10:24 < neg>       this task and don't want to commit to something which is not
+10:24 < neg>       feasible not to rush you Laurent :-)
+10:24 < neg> --eot--
+10:25 < pinchartl> thank you
+10:25 < pinchartl> let's discuss the object lifetime management with my report
+10:25 < pinchartl> well, I'm next :-)
+10:25 < pinchartl> Since last meeting:
+10:25 < pinchartl> - Finished the additional tasks descriptions for Q4
+10:25 < pinchartl> - Patch review and GMSL debugging discussions
+10:25 < pinchartl> - Started display color keying support for Gen3
+10:25 < pinchartl> Until next meeting:
+10:25 < pinchartl> - More patch review
+10:25 < pinchartl> - Complete display color keying support for Gen3
+10:25 < pinchartl> - V4L2 lifetime management issues (for VIN Gen3 support)
+10:25 < pinchartl> Issues and Blockers: None
+10:26 < pinchartl> so my plan is to handle object lifetime management after ELCE
+10:26 < pinchartl> but I'll be travelling the week right after ELCE and take two days off
+10:26 < jmondi> neg: I had missed "v4l: rdacm20: add log_status operation".. That's useful (sorry for the noise Laurent)
+10:26 < pinchartl> so my availabilities will be a bit reduced
+10:27 < pinchartl> as Niklas depends on that, I'll try to prioritize it over the weekends
+10:27 < pinchartl> and possibly during ELCE, but based on personal experience I can't do all the work I plan during conferences
+10:27 < pinchartl> neg: how would that work for you schedule-wise ?
+10:28 < pinchartl> and is the remove / ioctl race the only one blocking the VIN driver ?
+10:28 < neg> pinchartl: that would work and I would feel confident with my additional contract date. My concern is that I want to post the series as soon as possible so there is some time for review before the end of the contract :-)
+10:29 < neg> and yes the ioctl race (and a api to interact with it for controll handeling on Gen2) is all that is missing
+10:30 < pinchartl> let's see what I can get done over the weekend then
+10:30 < pinchartl> that's it for me
+10:31 < neg> n/p I wont postit before the 31st as I need to be in the office for full testing before sending it out
+10:31 < pinchartl> we've covered the topic of the next meeting already, it will be on November the 9th
+10:31 < pinchartl> how about meeting during ELCE ?
+10:32 < pinchartl> dammsan: any plan for that ?
+10:32 < dammsan> not apart from having dinner with marek
+10:32 < dammsan> but we can schedule something if needed
+10:33 < neg> I'm up for meeting anytime duinrg ELCE, but if possible not during ELCE time on Monday, too may good talks that day :-)
+10:33  * morimoto morimoto need to go back home
+10:33 < pinchartl> Tuesday or Wednesday should work. we'll see if there are topics to discuss
+10:33 < pinchartl> anything else for today ?
+10:33 < pinchartl> morimoto: have a nice evening
+10:34 < morimoto> thanks
+10:34 < morimoto> bye
+10:34 < jmondi> not from me.. bye Morimoto-san
+10:34 -!- morimoto [~user@relprex3.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"]
+10:34 < geertu> pinchartl: We forgot one thing w.r.t. next meeting: end of Daylight Savings Time
+10:35 < pinchartl> so what should we do ? :-)
+10:36 < uli__> panic!!
+10:36 < pinchartl> the time difference with Japan will increase by one hour
+10:36 < pinchartl> one option is to keep the same time in Japan and move the meeting earlier in Europe
+10:37 < pinchartl> but that would make it at 7:00 for Kieran, which is too early
+10:37 < pinchartl> so I propose the other way around, keeping the same time in Europe
+10:37 < pinchartl> dammsan: as you're in Japan, what do you think ?
+10:37 < geertu> +1
+10:37 < geertu> (although Kieran will be used to wake up all day soon ;-)
+10:38 < dammsan> sounds fine to me
+10:38 < dammsan> i think this will have a positive impact for japan side
+10:39 < pinchartl> good :-)
+10:39 < pinchartl> what kind of positive impact ?
+10:40 < Marex> keep that DST in mind when going to the airport in case you're departing after the DST switch please, so that you won't miss your flight
+10:40 < dammsan> more time before the meeting starts? =)
+10:40 < Marex> heh
+10:41 < pinchartl> that's it for today thn
+10:41 < pinchartl> thank you all for attending