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 :)