diff options
Diffstat (limited to 'wiki/Chat_log/20160525-mm-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160525-mm-chatlog | 478 |
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 :) |