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

1 files changed, 478 insertions, 0 deletions

diff --git a/wiki/Chat_log/20160525-mm-chatlog b/wiki/Chat_log/20160525-mm-chatlog
new file mode 100644
index 0000000..f0e3cd3
--- /dev/null
+++ b/wiki/Chat_log/20160525-mm-chatlog
@@ -0,0 +1,478 @@
+Multimedia-chat-meeting-2016-05-25
+
+<pinchartl> hello Morimoto-san
+<morimoto> Hi 
+<morimoto> sorry for my late
+<pinchartl> we've just started
+<pinchartl> no worries, you're excused
+<pinchartl> I've posted the topics for the day
+<pinchartl> Topic 1. Status check for the multimedia tasks
+<pinchartl> Topic 2. Additional '50%' tasks
+<pinchartl> Topic 3. New upstream DRM/KMS rules
+<pinchartl> Topic 4. Next meeting
+<pinchartl> would anyone like to add another topic ?  [17:02]
+<morimoto> I added Renesas request to peripelist
+<dammsan> hi guys, sorry about the delay
+<morimoto> (it was already requested by email to each member, but not listed)
+<pinchartl> in multimedia/request ?  [17:03]
+<morimoto> Yes
+<pinchartl> (kbingham: for your information, the lists of pending and
+	    requested tasks are maintained in text format in a git tree called
+	    peripelist)  [17:04]
+<kbingham> pinchartl: I see :)
+<pinchartl> I have a question about that, let's add it as a topic  [17:05]
+<pinchartl> Topic 4. Renesas requests
+<morimoto> thanks  [17:06]
+<pinchartl> let's get started with the status, and let's try to keep it short
+<morimoto> :)
+<pinchartl> in alphabetical order  [17:07]
+<pinchartl> FDP,v4.8,plan,laurent,Develop and upstream driver
+<pinchartl> (which is handled by Kieran, otherwise I wouldn't be first in
+	    alphabetical order)
+<pinchartl> kbingham: what's the status ?  [17:08]
+<kbingham> FDP1: M2M driver can handle frames, and support MPLANE/MPIX
+	   api. Now working with getting the hardware to do
+	   'something'. IPBlock is powered up, (using RuntimePM) and
+	   interrupts are firing. Not currently getting 'successful' FrameEnd
+	   status yet though.
+<kbingham> Switched to using OPMODE_INTERRUPT with a VPERIOD setting, and that
+	   fires regular VSyncs
+<pinchartl> do you have ideas regarding what to explore or are you getting
+	    blocked ?  [17:09]
+<kbingham> Starting to feel blocked. I've gone through most of the register
+	   settings, and the programming sequence and I'm running out of
+	   ideas. My next plan is to try moving away from Progressive mode and
+	   try de-int mode to see if there is a difference there but I fear
+	   that is complicating things rather than simplifying. The only other
+	   thing I have thought needs checking is the FCP  [17:10]
+<pinchartl> have you linked the FDP to the FCP in DT ?  [17:11]
+<kbingham> No!  [17:12]
+<kbingham> That sounds like a step I've missed :)
+<pinchartl> and do you call rcar_fcp_enable() and rcar_fcp_disabled() in your
+	    driver ?
+<kbingham> Ok - I'm unblocked :)
+<pinchartl> at least temporarily :-)
+<pinchartl> the FCP driver isn't upstream yet
+<pinchartl> you need to get it from my git tree at
+	    git://linuxtv.org/pinchartl/media.git  [17:13]
+<kbingham> I do have a pending action to confirm the CPG clock parents
+	   though. morimoto - are you able to look into that for me?
+<pinchartl> branches drm/next/dt and vsp1/next
+<kbingham> pinchartl: Ok - thanks. I'll get on that  next.
+<morimoto> kbingham: can you send question email to me or periperil ML ?
+								        [17:14]
+<morimoto> kbingham: I can send it to HW / datasheet guys
+<kbingham> morimoto: Sure. I'll send a dedicated mail. thanks :)
+<morimoto> kbingham: np
+<pinchartl> next, Magnus  [17:15]
+<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen2
+<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen3
+<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen2
+<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen3
+<pinchartl> no progress on that I assume ?
+<dammsan> nothing done yet, but i intend to try Gen3 early next month
+<dammsan> with VIN in mean
+<pinchartl> but not with the IPMMU, right ?  [17:16]
+<dammsan> s/in/i/g
+<dammsan> test with the IPMMU
+<dammsan> just to figure out what is needed
+<pinchartl> so we're not blocked by the IPMMU hardware bug anymore ?
+<morimoto> kbingham: for your information: I asked to BSP team about FDP
+	   sample code / test code now. I'm not sure it exists or not. please
+	   wait :)
+<dammsan> it is probably flakey on H3
+<dammsan> but worth looking into to see what our limitations are  [17:17]
+<dammsan> M3 may work better
+<kbingham> morimoto: Thanks. Will be useful reference if it exists.
+<dammsan> same situation as DU
+<pinchartl> morimoto: thank you !
+<pinchartl> morimoto: there's a 'fdpm-driver.tar.bz2' archive mentioned in the
+	    yocto recipes, but that file is nowhere to be found  [17:18]
+<pinchartl> so I assume code exists
+<pinchartl> dammsan: thanks
+<dammsan> np
+<pinchartl> next, morimoto
+<pinchartl> RSND,2016-06-30,plan,morimoto,DT bindings for HDMI sound
+<pinchartl> RSND,2016-06-30,plan,morimoto,dw-hdmi-ahb-audio prototype on Gen3
+<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI SSI prototype on Gen3
+<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI sound Upstream support without
+	    hotplug on Gen2
+<pinchartl> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3
+<morimoto> graph base HDMI sound needs hack.  [17:19]
+<morimoto> I posted its 1st step patches to ALSA and Renesas ML
+<morimoto> It is under reviewing now
+<morimoto> And now, I'm hacking of prototype of graph base sound card
+<morimoto> not yet finished.
+<morimoto> over  [17:20]
+<dammsan> (and i bothered morimoto-san by asking about HDMI-in audio-input)
+<pinchartl> as you've posted patches, which of the tasks should now be
+	    'public'  [17:21]
+<morimoto> I'm bothering it, yes
+<morimoto> well...
+<morimoto> RSND,2016-06-30,plan,morimoto,DT bindings for HDMI sound
+<morimoto> but, 30% for it
+<morimoto> 30% of it  [17:22]
+<pinchartl> I wonder how to report the 30% in the tasks list :-)
+<pinchartl> should I leave it as 'plan' for now until we reach 50% ?  [17:23]
+<morimoto> can you separate it into more small tasks ?
+<morimoto> split ? separate ?
+<pinchartl> sure  [17:24]
+<pinchartl> how would you like me to split it ?
+<morimoto> 1. clean up simle-card  [17:25]
+<morimoto> 2. create simple-card core
+<morimoto> 3. share simple-card core with DPCM
+<morimoto> 4. share simple-card core with graph
+<morimoto> 5. use graph simple-card on ASoC
+<morimoto> 6. use graph simple-card on Gen2
+<morimoto> 7. use graph simple-card on Gen3
+<morimoto> 
+<morimoto> Maybe these are enough
+<morimoto> 1, 2, 3 are posted
+<morimoto> I mean public
+<pinchartl> that's very fine-grained. do we really need to go to that level of
+	    details in the tasks list, or can I just list that in the meeting
+	    report ?  [17:27]
+<morimoto> OK, please wait
+<morimoto> I will clean up again
+<pinchartl> thanks  [17:28]
+<pinchartl> I'll include that in the report anyway
+<pinchartl> I'll move on to Niklas' tasks in the meantime
+<pinchartl> ADV7482,v4.7,plan,niklas,Prototype on Gen3
+<pinchartl> ADV7482,v4.9,plan,niklas,Gen3 support upstream
+<pinchartl> ADV7482,v4.9,plan,niklas,Interlace support upstream
+<pinchartl> VIN,v4.7,plan,niklas,CSI2 prototype (Gen3)  [17:29]
+<pinchartl> VIN,v4.8,plan,niklas,Gen3 support
+<pinchartl> VIN,v4.8,plan,niklas,Scaler support (on Gen3)
+<pinchartl> VIN,v4.8,public,niklas,New VIN driver without soc-camera (tested
+	    on Gen2)
+<pinchartl> VIN,v4.9,plan,niklas,CSI2 interlace support upstream (Gen3)
+<pinchartl> VIN,v4.9,plan,niklas,CSI2 support upstream (Gen3)
+<pinchartl> VIN,v4.9,plan,niklas,Gen3 support upstream (without CSI-2)
+<neg> I will post the Gen3 VIN patches today
+<pinchartl> including CSI ?  [17:30]
+<neg> yes it will include the CSI2 and ADV7482 prototypes from BSP with some
+      small fixes ontop
+<pinchartl> so that covers
+<pinchartl> - ADV7482,v4.7,plan,niklas,Prototype on Gen3
+<pinchartl> - VIN,v4.7,plan,niklas,CSI2 prototype (Gen3)
+<pinchartl> - VIN,v4.8,plan,niklas,Gen3 support  [17:31]
+<pinchartl> right ?
+<neg> yes,  but I will not include the CSI2 and ADV in the patch sereis but
+      make them avaliable in a topic branch for testing
+<neg> so I don't think they should be marked public
+<pinchartl> for prototype patches that's fine, and I think it's enough to
+	    consider them as public  [17:32]
+<neg> OK
+<pinchartl> are the Gen3 support patches in a good enough shape to be reviewed
+	    ?
+<pinchartl> or are they prototype code ?
+<neg> yes I hope they are ready for review, they use s_input for input
+      selection which we might not want to commit to. But I think it worked
+      out OK  [17:33]
+<pinchartl> ok, thanks
+<morimoto> pinchartl: hmm.. then, current task list is enough ;)  [17:34]
+<morimoto> pinchartl: can you set "DT bindings for HDMI sound" as "public" ?
+<morimoto> 
+<pinchartl> morimoto: sure
+<morimoto> kbingham: we got FDP sample code from BSP team. I will send it to
+	   you
+<pinchartl> morimoto: great !
+<kbingham> morimoto: Thanks!
+<pinchartl> neg: no progress on the other tasks I assume  [17:35]
+<neg> at lest you can grab frame from both HDMI and CVBS sources on both Gen2
+      and Gen3
+<neg> pinchartl: yes no progress on the rest
+<pinchartl> ok
+<pinchartl> are we still on track with the targets ?  [17:36]
+<pinchartl> - VIN,v4.8,plan,niklas,Scaler support (on Gen3)
+<pinchartl> - VIN,v4.8,public,niklas,New VIN driver without soc-camera (tested
+	    on Gen2)
+<pinchartl> and the rest is for v4.9
+<pinchartl> I think we are
+<neg> yes I think so
+<pinchartl> so do I, good :-)
+<pinchartl> next, uli___  [17:37]
+<pinchartl> DU,v4.7,plan,ulrich,Atomic API test program
+<pinchartl> DU,v4.7,public,ulrich,HDMI output on Gen3 prototype
+<pinchartl> DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input
+	    loopback (without EDID)
+<pinchartl> DU,v4.7,public,ulrich,EDID generation support for the HDMI
+	    loopback test setup
+<pinchartl> DU,v4.8,plan,ulrich,HDMI output on Gen3 upstream
+<pinchartl> VIN,v4.8,public,ulrich,Add DV timings support to rcar-vin
+<uli___> api test is in progress right now
+<uli___> hdmi output i will brush up and make public as an rfc before the end
+	 of the month  [17:38]
+<uli___> gen3 i mean
+<uli___> dv for r-car vin is at v4 now
+<uli___> hans's complaints are limited to the fixed edid blob
+<uli___> gotta implement s_edid/g_edid instead
+<uli___> that's about it for now  [17:39]
+<morimoto> uli___: Is renesas-driver including your latest HDMI out code ? I
+	   still have HDMI1_OUT issue on latest renesas-driver
+<uli___> there is a topic branch, iirc  [17:40]
+<morimoto> OK
+<pinchartl> as the HDMI out prototype is an additional task please make sure
+	    with Geert that the topic branch is merged in the renesas-drivers
+	    tree
+<uli___> topic/salvator-x-hdmi-prototype-v2
+<pinchartl> thanks  [17:41]
+<morimoto> thanks,
+<pinchartl> I'll keep HDMI loopback targetted at v4.7 as it's due for end of
+	    June  [17:42]
+<uli___> yes
+<pinchartl> I don't think 'DU,v4.8,plan,ulrich,HDMI output on Gen3 upstream'
+	    will make it to v4.8  [17:43]
+<uli___> probably not
+<pinchartl> I'll push it back to v4.9
+<pinchartl> next, me  [17:44]
+<uli___> (what happened to the alphabetical order, anyway?)
+<uli___> scnr
+<pinchartl> good question :-)
+<pinchartl> DU,?,plan,laurent,IPMMU integration on Gen3  [17:45]
+<pinchartl> DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP)
+<pinchartl> no progress
+<pinchartl> DU,v4.8,public,laurent,VSPD Z-order support upstream (Gen3)
+<pinchartl> still public :-)  [17:46]
+<pinchartl> the patches missed the v4.7 merge window, they will make it to
+	    v4.8  [17:47]
+<pinchartl> VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA)
+<pinchartl> VSP,?,plan,laurent,CLU WARN_ON fix
+<pinchartl> VSP,?,plan,laurent,CLU 2D and 3D mode support
+<pinchartl> VSP,?,plan,laurent,CLU/LUT test application
+<pinchartl> VSP,?,plan,laurent,CLU/LUT upstream API
+<pinchartl> no progress
+<pinchartl> CLU support is an additional task for June  [17:48]
+<pinchartl> I'll mark it for v4.8
+<pinchartl> VSP,?,plan,laurent,UDS regression fix  [17:49]
+<pinchartl> no progrss
+<pinchartl> I plan to have a look at it in June, v4.8 as well
+<pinchartl> VSP,v4.8,plan,laurent,Fix suspend/resume crash  [17:50]
+<pinchartl> no progress
+<pinchartl> VSP,v4.8,public,laurent,CLU/LUT support submitted upstream on Gen3
+<pinchartl> no progress either, still on track for v4.8 with the rest of the
+	    CLU tasks  [17:51]
+<pinchartl> VSP,v4.8,p,laurent,HGO operation mode selection
+<pinchartl> VSP,v4.8,plan,laurent,HGO support upstream on Gen3
+<pinchartl> VSP,v4.8,plan,laurent,HGO test application
+<pinchartl> patches are now public
+<pinchartl> on track for v4.8
+<pinchartl> testing doesn't require a new test application  [17:52]
+<pinchartl> patches to yavta test tool have been pushed to the repository in a
+	    topic branch until the API changes get accepted upstream
+<pinchartl> and test scripts have been pushed to a new project  [17:53]
+<pinchartl> git://git.ideasonboard.com/renesas/vsp-tests.git
+<pinchartl> this is an initial attempt at creating unit tests for the vsp
+	    driver
+<pinchartl> if anyone is interested I can elaborate on that  [17:55]
+<uli___> i would be...
+<pinchartl> ok, let's address that as a separate topic
+<pinchartl> VSP,v4.8,public,laurent,V4L2 request API usable prototype  [17:56]
+<pinchartl> VSP,?,prototype,laurent,V4L2 request API upstream
+<pinchartl> progress :-)
+<pinchartl> but not posted yet, I will for the end of the month, which means
+	    the end of the week
+<pinchartl> that's it for the tasks
+<pinchartl> Topic 2. Additional '50%' tasks
+<pinchartl> has everybody received their additional tasks for June ?  [17:57]
+<pinchartl> ('everybody' being Niklas and Ulrich)
+<uli___> you have sent something to magnus, not sure what became of that :)
+								        [17:58]
+<neg> yes I got task descriptions from Magnus today
+<pinchartl> dammsan: what's the status ?  [17:59]
+<pinchartl> anything needed on our side, or is everything in the pipeline ?
+<pinchartl> while waiting for Magnus to reply
+<pinchartl> is everybody on track with their additional tasks for May ?
+								        [18:00]
+<morimoto> (dammsan is talking to Renesas guy now, please wait)
+<pinchartl> the report needs to be a bit more detailed than what we are used
+	    to
+<pinchartl> and should really not miss the deadline
+<pinchartl> neg: uli___: are you all good ?
+<uli___> i am  [18:01]
+<neg> yes, I'm fine
+<pinchartl> great
+<pinchartl> I am as well
+<dammsan> pinchartl: need to finalize one bit with wolfram to cover uli___
+<neg> Only outstading issue I have is to ping geert for a topic branch in
+      renesas-drivers but I think that is OK to contain prototype code right?
+								        [18:02]
+<dammsan> but i hope to do so today or tomorrow
+<dammsan> to have final review on friday
+<pinchartl> neg: it is, yes. if you push your patches to a git tree and send a
+	    pull request to Geert for renesas-drivers that's enough for the
+	    report
+<pinchartl> dammsan: thanks
+<neg> pinchartl: great thanks
+<pinchartl> Topic 3. New upstream DRM/KMS rules  [18:04]
+<pinchartl> this one is a rather bad one
+<pinchartl> DRM/KMS has long required GPU kernel drivers to have an
+	    open-source userspace implementation in order to get merged
+<pinchartl> that's at least how the rule was communicated interpreted  [18:05]
+<pinchartl> they're now changing, if not their base rule, at least how they
+	    apply it
+<pinchartl> and require open-source userspace upstream code for any new kernel
+	    API
+<pinchartl> including driver-specific properties
+<pinchartl> z-order and alpha support got accepted right before they decided
+	    to enforce that rule  [18:06]
+*** horms (~horms@reginn.isobedori.kobe.vergenet.net) has quit: Quit: Leaving
+<pinchartl> but from now on, an implementation in Android hardware composer,
+	    wayland or X11 will be required for any API extension
+<pinchartl> this is a major issue for us
+<pinchartl> as our team works on the kernel side only  [18:07]
+<pinchartl> not only don't we have the bandwidth to cover the userspace side
+<pinchartl> but userspace is the responsibility of other teams within Renesas,
+	    and we can't claim ownership of those areas
+<pinchartl> the new rule will be announced shortly  [18:08]
+<pinchartl> there will likely be a grace period
+<pinchartl> but we'll have to adjust
+<pinchartl> I've learnt about that yesterday and don't have a plan yet
+<pinchartl> any comment ?
+<uli___> so does the userspace part only have to exist somewhere, or does it
+	 really have to be upstream?  [18:09]
+<pinchartl> it has to be acked by upstream developers
+<pinchartl> not merged obviously, as it can't be merged before the kernel API
+	    is available  [18:10]
+<morimoto> does z-order and alpha support will be updated ?
+<pinchartl> they will be merged in v4.8 as they have been accepted right
+	    before the change of rule  [18:11]
+<pinchartl> but if they hadn't been
+<pinchartl> we would have had to submit patches to android hwcomposer, weston
+	    or X11 to use Z-order and alpha
+<pinchartl> so this might mean we'll have to collaborate with the Renesas
+	    upstream developers  [18:14]
+<pinchartl> s/upstream/userspace/
+<pinchartl> I'll bring that topic up during the meeting in Japan
+<pinchartl> any suggestion regarding what to do in the meantime will be
+	    welcome  [18:15]
+<pinchartl> while this sinks in
+<pinchartl> Topic 4. Renesas requests
+<pinchartl> Morimoto-san, you've updated multimedia/request  [18:16]
+<pinchartl> how are we supposed to handle that list ?
+<pinchartl> is it just there to keep track of the request, and let us propose
+	    additional tasks (or handle them as part of the base contract), or
+	    do we need to be more proactive ?  [18:17]
+<morimoto> It is not a big deal, just for my / Renesas information
+<morimoto> I sometimes requests something, and clean forgot :)  [18:18]
+<pinchartl> ok, so no action required from me, apart from looking at it and
+	    using it as a source of inspiration to propose tasks ?
+<morimoto> I would like to track what is requested, and current status
+<morimoto> something like that  [18:19]
+<pinchartl> thanks  [18:20]
+<pinchartl> Topic 5. VSP unit tests
+<pinchartl> as I mentioned earlier, we now have a vsp unit tests framework
+<pinchartl> it's implemented as a set of shell scripts using the yavta and
+	    media-ctl test tools
+<pinchartl> as well as the compare utility from ImageMagick  [18:21]
+<pinchartl> on the host side python is also needed to generate test data
+<pinchartl> there are 8 tests so far, and they already allowed me to catch two
+	    bugs in the vsp driver, for which I've submitted patches
+<pinchartl> I plan to add more test script in the future
+<pinchartl> and will also need to work on creating a new test tool to generate
+	    test data (both input reference frames and excepted output frames
+	    for comparison) at runtime instead of build time  [18:22]
+<pinchartl> as there's already 230MB of test frames, and that won't scale
+<pinchartl> new test scripts will be added as I develop driver features
+<pinchartl> and I'll propose an additional task for work on the test framework
+	    core, as that will need quite a bit of time  [18:23]
+<pinchartl> I encourage you all to start thinking about unit test scripts for
+	    the driver(s) you work on
+<kbingham> pinchartl: I'd been looking at gstreamer as a potential for testing
+	   my M2M driver - as the Videotestsrc element will enable me to
+	   create many types of frames consistently - dynamically.
+<pinchartl> feel free to use vsp-tests as a base and provide feedback
+<pinchartl> for the FDP I think that's an option  [18:24]
+<pinchartl> it would depend on gstreamer obviously, but that shouldn't be a
+	    too big deal
+<pinchartl> on the other hand  [18:25]
+<pinchartl> gstreamer will only exercise the API as it's meant to be used
+<pinchartl> if you want to unit-test the error paths then you'll need
+	    something at a lower level
+<kbingham> yes. that's true.
+<pinchartl> but you can have diffrent unit test scripts that use different
+	    tools  [18:26]
+<pinchartl> I'm fine with gstreamer, but if you realize that you could perform
+	    the exact same tests easily with less dependencies, then I'd
+	    prefer avoiding gstreamer
+<pinchartl> if it brings added value, then no worries
+<kbingham> Ok - I'll bear that in mind :)  [18:27]
+<pinchartl> regarding the test scripts themselves, we should standardize on
+	    naming, output and other technical details to make sure they could
+	    all be run from a single test runner, and generate a coherent
+	    report
+<pinchartl> I haven't given that much thoughts yet on my side
+<pinchartl> if you start writing unit test scripts please get in touch with me
+	    to discuss those points  [18:28]
+<pinchartl> that's all I have on this topic  [18:29]
+<pinchartl> Topic 5. Next meeting
+<pinchartl> I propose Wednesday in two weeks (8th of June), same time as today
+<kbingham> Ok for me.  [18:30]
+<uli___> me too
+<neg> OK for me
+<morimoto> OK for me too
+<pinchartl> dammsan: ?
+<morimoto> (Mr Magnus is still taling to Renesas guy)
+<pinchartl> ok :-)
+<pinchartl> I assume he will voice his concerns over e-mail if there's any
+	    issue
+<pinchartl> we're done with the agenda, any last remark or question ?  [18:31]
+<morimoto> pinchartl: thank you for your new topic for RenesasCon
+<pinchartl> you're welcome
+<pinchartl> it's two new topics actually  [18:32]
+<pinchartl> I plan to talk about the test framework too
+<pinchartl> in addition to the DRM/KMS rule change
+<pinchartl> but regarding the test framework
+<pinchartl> we should discuss it internally first before adding the topic to
+	    the RenesasCon agenda
+<pinchartl> we can talk about it during the next multimedia meeting, I will
+	    hopefully have a bit more information by then  [18:33]
+<pinchartl> and others will hopefully have time to give it a look too :-)
+<pinchartl> I propose adjourning for today. does everybody second ?  [18:34]
+<kbingham> Seconded :)
+<pinchartl> thank you for joining everybody  [18:35]
+<pinchartl> have a nice day
+<uli___> cu
+<neg> thanks all  [18:36]
+<kbingham> Thanks :)
+<morimoto> pinchartl: it seems we need Kurokawa-san to next meeting ?
+<morimoto> for DRM/KMS topis  [18:37]
+<morimoto> topis/topics
+<pinchartl> morimoto: that could be useful
+<morimoto> OK
+<morimoto> thanks
+<pinchartl> I'd like to think about it for a couple of days and then discuss
+	    it with you and Magnus
+<morimoto> OK. by chat ?  [18:38]
+<pinchartl> or e-mail  [18:40]
+<pinchartl> both are fine with me
+<pinchartl> I'll likely chat with Magnus about this when he won't be busy with
+	    "the Renesas guy" :-)  [18:41]
+<morimoto> OK :)
+<morimoto> I can ask it to him, after kicking Renesas guy :)  [18:42]
+<morimoto> kbingham: can I ask you ?
+<morimoto> kbingham: are you still there ?
+<kbingham> morimoto: I'm here :)
+<morimoto> thanks. does your question about FDP parent clock  [18:43]
+<kbingham> morimoto: How can I help ?
+<morimoto> does it just parent clock for CPG ?
+<morimoto> or do you have some issue on it ?  [18:44]
+<kbingham> morimoto: Thats correct.
+<morimoto> OK, so you have no big issue now
+<kbingham> morimoto: I don't think there is an issue currently. I can read and
+	   write to the registers - so I assume we have it right, but I don't
+	   have a datasheet clock diagram to confirm it is correct (and not
+	   that I'm just lucky and something else has actually turned the
+	   clock on for me)
+<pinchartl> morimoto: it's the usual "what is the correct parent for the MSTP
+	    clock" question. the FDP doesn't care about the clock rate so it's
+	    no big deal, it's just about correctness  [18:45]
+<pinchartl> (I'll be back in 20 minutes)
+<morimoto> Yeah, same here.
+<morimoto> According to HW / datasheet guys, they decided to indicate it in
+	   block diagram  [18:46]
+<morimoto> but, not yet completed
+<morimoto> OK, thanks. I asked it to HW / datasheet guys. please wait  [18:47]
+<kbingham> morimoto: Ok - so just waiting on them finishing the document.
+<morimoto> Thanks
+<kbingham> morimoto: Thankyou :)