diff options
Diffstat (limited to 'wiki/Chat_log/20160913-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160913-core-chatlog | 368 |
1 files changed, 368 insertions, 0 deletions
diff --git a/wiki/Chat_log/20160913-core-chatlog b/wiki/Chat_log/20160913-core-chatlog new file mode 100644 index 0000000..b33fee4 --- /dev/null +++ b/wiki/Chat_log/20160913-core-chatlog @@ -0,0 +1,368 @@ +Core-chat-meeting-2016-09-13 + +10:03 < geertu> Welcome to the 25th edition of the Renesas Core Group Chat! +10:05 < morimoto> hi +10:05 < geertu> pinchartl will be a few minutes late +10:06 < geertu> dammsan may prefer improving his Japanese? +10:06 < geertu> Today's Agenda: +10:06 < geertu> 1. Status updates +10:06 < geertu> 2. Handling differences between R-Car H3 ES1.x and ES2.0 +10:07 < geertu> Topic 1. Status updates +10:07 < geertu> A) What have I done since last time +10:07 < geertu> B) What I plan to do till next time +10:07 < geertu> C) Problems I have currently +10:07 < dammsan> geertu: i'm here! +10:07 < geertu> dammsan: great! +10:07 < geertu> "sort -R" ... (virtual dices are rolling) ... +10:07 < geertu> Niklas! +10:08 < neg> a) implemented drive strength for non-I/O pins on a pin level and it works +10:08 < neg> b) post the patches for drive strength +10:08 < neg> c) Some trouble getting none I/O poins to work on a group level, sh-pfc assumes the pin can be muxed but when that fails for the none I/O pins it bails-out and the configuration is not applied to the group. Is This something we wish to change or should drive-strength for example only be able to set on a pin basis? Looking at the state u-boot leaves the AVB pins not all pins are set to the same +10:08 < neg> drive-strength level. +10:10 < geertu> I don't know. Any RAVB experts around? +10:10 < horms> i have dabbled in ravb but I am not sure about that question +10:11 < horms> you may get some value from talking with sergei, he seems to take particular interest in ravb +10:11 < horms> And he seems to like a quick chat on #renesas-soc +10:12 < geertu> Adding to that, posting a first version as an RFC never hurts, and may attract comments. +10:14 < geertu> Anything else? +10:14 < neg> no I will post a RFC and take it from there, thanks +10:14 < geertu> Thanks Niklas! +10:14 < geertu> Next is me, myself, and I: +10:15 < geertu> A) - Received and lightly tested M3-W/Salvator-X board, thanks! +10:15 < geertu> - Reviewed lots of patches to add (DT) support for new boards +10:15 < geertu> B) - Continue RST, MODEMR, ES-handling, ... +10:15 < geertu> - 64-bit memory with M3-W Ethernet +10:15 < geertu> C) Nothing +10:15 < geertu> (or perhaps more time and deduplication into Me, Myself, and I) +10:16 < pinchartl> what's the status of MODEMR ? +10:16 < khiemnguyen> good question. +10:16 < geertu> pinchartl: No change +10:17 < geertu> and Stephen Boyd came with the suggestion to use the shiny new nvmem API instead +10:17 < pinchartl> I've seen that +10:17 < pinchartl> I don't like it much +10:17 < geertu> OK, that makes two of us. +10:17 < geertu> Feel free to chime in ;-) +10:17 < pinchartl> especially due to the fact that we have to reference the nvmem DT node around +10:18 < geertu> Even syscon sounded better ;-) +10:19 < geertu> Next is Shimoda-san: +10:19 < shimoda> yes +10:20 < shimoda> A) What have I done since last time +10:20 < shimoda> I'm continue to investigate on Gen3 USB EHCI + IPMMU issue. So, nothing for core. +10:20 < shimoda> B) What I plan to do till next time +10:20 < shimoda> I should describe an explanation of "Lossy" into eLinux... +10:20 < shimoda> C) Problems I have currently +10:20 < shimoda> About core tasks, nothing for now. +10:20 < shimoda> end +10:20 < geertu> Thanks Shimoda-san! +10:20 < geertu> Next is pinchartl: +10:22 < pinchartl> no core task for me +10:22 < pinchartl> and nothing planned +10:22 < geertu> Thanks Laurent! +10:22 < geertu> Next is Simon: +10:22 < pinchartl> I'll need h3 ES2.0 support at some point to develop multimedia-specific features +10:22 < dammsan> pinchartl: can you hook up via google chat and discuss things with me +10:22 < pinchartl> but let's discuss that as part of the second topic +10:23 < pinchartl> dammsan: done +10:23 < pinchartl> (not the discussion, just the connection) +10:23 < dammsan> thanks +10:26 < pinchartl> horms: the stage is yours +10:26 < horms> A) What have I done since last time +10:26 < horms> * Verified Kexec on M3-W +10:26 < horms> - works fine with v4.8-rc2 +10:26 < horms> - user-space patches edging towards merge +10:26 < horms> - http://www.elinux.org/Tests:r-car-gen3-kexec +10:26 < horms> * Received and lightly tested M3-W/Salvator-X board, thanks! +10:26 < horms> B) What I plan to do till next time +10:26 < horms> * Finalise Kexec-to-RAM work by documenting hw/sw stack, writing report, etc... +10:26 < horms> C) Problems I have currently +10:27 < horms> * Ethernet integration plan +10:27 < geertu> For C, I think that'll be assigned to me soon, as an additional task incl. 64-bit memory +10:28 < horms> great +10:28 < horms> one more: +10:28 < horms> * SDR50 on Gose SDHI1 - may relate to voltage switching??? +10:28 < horms> --- end --- +10:28 < pinchartl> geertu: as far as I know RAVB doesn't have support for 64-bit memory +10:29 < geertu> pinchartl: Cool, so that part is gonna fail. But in the end it should work anyway... +10:30 < horms> my research indicated that almost none of the ip blocks have 64bit support as such +10:30 < horms> so i suppose the ipmmu will become central +10:30 < pinchartl> horms: agreed +10:31 < pinchartl> geertu: it will work with the IPMMU but won't without +10:31 < pinchartl> (after we enable 64-bit memory) +10:31 < geertu> pinchartl: or with bounce buffers... +10:31 < horms> so hopefully the imppu works :^) +10:31 < horms> so hopefully the ipmmu works :^) +10:32 < geertu> Let's see... +10:32 < pinchartl> geertu: ouch. indeed. let's try not to :-) +10:33 < dammsan> geertu: you got my update via email +10:33 < dammsan> basically IPMMU stuff for A) and B) +10:33 < dammsan> need to update the bootloader so that may turn into C) worst case +10:34 < pinchartl> dammsan: have you had time to check the IOMMU patches posted by Sricharan ? +10:34 < geertu> dammsan: How did you know you were next (yes yoy are!), after Simon? +10:35 < geertu> s/yoy/you/ +10:35 < geertu> Thanks Simon +10:35 < geertu> Thanks Magnus ;-) +10:36 < geertu> Next is Ul(r)i(ch): +10:36 < uli___> A) Integrated SYS-DMAC on M3-W +10:36 < uli___> B) Test SYS-DMAC integration and post the patches +10:36 < uli___> C) See agenda 2. +10:36 < uli___> plus, for a) m3-w boards works for me, too +10:37 < uli___> for c) the growing stack of boards obscures my view on the monitor +10:37 < uli___> cannot move it because the ethernet cable is too short +10:37 < uli___> i also lost my glasses +10:37 < uli___> life is miserable +10:37 < uli___> that's it +10:37 < geertu> Sorry to hear about your glasses +10:37 < geertu> I can understand you can't extend the Ethernet cable now ;-) +10:38 < uli___> if the sign says, "don't use the water slide with glasses", i recommend to listen :) +10:38 < horms> haha +10:38 < horms> i can send you some ethernet cables if that would cheer you up +10:38 < uli___> thanks, but i'll find something, i'm sure :) +10:38 * geertu has strong glasses, all Ethernet cables are too long +10:40 < geertu> uli: For agenda 2, I guess you mean ES2.0? +10:40 < uli___> i was thinking about distinguishing between ES revisions +10:40 < uli___> is that what this is about? +10:40 < geertu> That's one part of it. +10:41 < geertu> Thanks Ulrich! +10:41 < geertu> next is Morimoto-san: +10:41 < morimoto> A) No Core Task. But Coming out myself to Geert +10:41 < morimoto> B) No plan +10:41 < morimoto> C) No issue +10:41 < morimoto> --end-- +10:42 < geertu> morimoto: You were wondering about +10:42 < geertu> Reset,2016-12-31,request,?,Upstreaming and Test +10:42 < geertu> PM,2017-03-31,request,Simon,Upstreaming and Test +10:42 < geertu> ? +10:42 < morimoto> Yes +10:42 < pinchartl> morimoto: congratulataions for your new son :-) +10:42 < geertu> For the former: +10:42 < geertu> - System reset is handled by PSCI, and works (try typing "reboot") +10:42 < geertu> - Watchdog reset also works +10:42 < geertu> - Did you have anything else in mind? +10:42 < morimoto> Is it already upstreamed ? +10:43 < morimoto> pinchartl: thanks. bit son :) +10:43 < morimoto> s/bit/big/ +10:44 < geertu> morimoto: Watchdog is in -next, for both h3 and m3-w +10:44 < geertu> morimoto: The rest is standard PSCI, nothing to upstream +10:45 < morimoto> OK, sounds nice. So I will remove "Reset" line from reqest +10:45 < morimoto> How about PM ? +10:45 < geertu> That's s2ram? Simon? +10:46 < khiemnguyen> PM = ? +10:46 < morimoto> s2ram +10:46 < horms> Sorry, what is the question? +10:46 < horms> s2ram status on gen3? +10:47 < morimoto> Yes +10:47 < morimoto> Ahh, this ?generic,2016-08-15,plan,simon,r8a7796 s2ram prototype +10:47 < horms> Suspend and resume seems to function, there are some caveats +10:47 < horms> Magnus describes them as meaning it doesn't work +10:47 < horms> 1. ethavb resume was broken. I believe that has been fixed. neg? +10:48 < horms> 2. The big problem: firmware work around for ddr training causes the system to resume in < 1s +10:48 < khiemnguyen> morimoto: you are mentioned about latest S2RAM in Yocto v2.12.0 ? +10:48 < geertu> horms: yes, ravb resume has been fixed +10:48 < horms> ok, good +10:48 < horms> one less problem +10:48 < horms> i'm unsure what the timeframe is for resolving #2 +10:48 < morimoto> OK, I wounder is it listed on "todo" file ? +10:49 < morimoto> as task +10:49 < geertu> morimoto: No, the todo file contains kernel tasks only +10:49 < morimoto> Ahh, OK +10:49 < horms> i think the task would be to co-ordiante with firmware team to get a fix. +10:50 < morimoto> OK, thanks +10:50 < dammsan> horms: yes, thanks! +10:51 < morimoto> horms: should I do something for it ? +10:51 < morimoto> I mean I need to ask to firmware team ? +10:51 < horms> I think we should talk to the firmware team +10:51 < horms> and yes, if you could do that I think that would be great +10:52 < horms> perhaps there is a way to get s2ram working without breaking ddr +10:52 < horms> or perhaps I missunderstand the situation somehow +10:52 < horms> or perhaps magicaally everyething will be prefect somehow :) +10:53 < morimoto> Oops, I remember we need new firmware for it ? I'm not sure +10:53 < morimoto> v2.12.0 I mean +10:53 < horms> Is that a firmware version I could test. e.g. on my shiny m3-w board? +10:54 < horms> Or perhaps its installed on a board that could be used to test +10:54 < horms> really its very easy to reproduce +10:54 < horms> 1. boot stock kernel +10:54 < horms> 2. echo mem > /sys/power/state +10:54 < horms> 3. wait < 1s +10:55 < horms> If the system wakes up, probably the problem is still there +10:55 < morimoto> Maybe v2.12.0 firmware is needed, but we don't have it at this point +10:55 < horms> ok +10:55 < horms> lets discuss with the firmware team +10:55 < horms> can you do that? +10:55 < morimoto> OK, will do +10:55 < horms> thanks! +10:55 < morimoto> For H3 ? M3 ? both ? +10:56 < horms> both +10:56 < morimoto> OK, +10:58 < khiemnguyen> horms: each driver need to be updated, to backup register context. Otherwise, resume will fail. +10:59 < horms> ok. even drivers that can resume on gen2? +10:59 < geertu> khiemnguyen: Wait, so it is a deeper sleeper than s2ram on Gen2? +11:00 < khiemnguyen> geertu: yes +11:01 < khiemnguyen> at suspended state, the board will shutdown, only power of DDR region will be kept. +11:01 < shimoda> khiemnguyen: is it gen3? not gen2. +11:01 < khiemnguyen> and you need one I2C command to set DDR backup mode, before calling S2RAM. +11:02 < khiemnguyen> It's Gen3. +11:02 < khiemnguyen> ....are we talking about Gen3 ? +11:02 < geertu> khiemnguyen: What does suspend to RAM do now? I thought it did the real suspend, but woke up early due to the need to do something with DDR? +11:03 < horms> thats what i thought +11:03 < geertu> "and you need one I2C command to set DDR backup mode, before calling S2RAM." may be an issue, as AFAIK everything is "handled" in core arm64 code by calling into PSCI. +11:03 < morimoto> khiemnguyen: does your comment based on BSP local implementetion ? +11:04 < khiemnguyen> morimoto: yeah +11:06 < dammsan> [1;5Cit's like upstream first, but not +11:08 < khiemnguyen> morimoto: so, for S2RAM, will we support similar S2RAM mechanism, like in Yocto v2.12.0 ? +11:10 < khiemnguyen> or we just enable S2RAM and fix drivers issues, if any +11:10 < pinchartl> (just FYI, I have to leave at 12:30 EEST sharp) +11:10 < geertu> Ok, let's handle this offline (on periperi ML) +11:10 < geertu> Thanks Morimoto-san! +11:11 < morimoto> geertu: thanks +11:11 < geertu> Next (and final) is Khiem: +11:13 < khiemnguyen> a) No update. +11:13 < khiemnguyen> b) Gen3 CPUFreq (Z clk changing) +11:13 < khiemnguyen> I missed v4.9. Will try v4.10. +11:13 < khiemnguyen> Please comment if any. +11:14 < khiemnguyen> c) My current mail client is Outlook. It's not able to use other email clients for now. under discussion with IT members. +11:14 < khiemnguyen> My last Thermal patches got problem when sending out. Could not see it in patchwork... +11:14 < khiemnguyen> That's all. +11:14 < pinchartl> khiemnguyen: to send patches I recommend git-send-email :-) +11:15 < geertu> khiemnguyen: Can you let git send-email talk to the Exchange server directly through SMTP? +11:15 < pinchartl> geertu: exchange might still rewrite the mail though and replace tabs with spaces +11:15 < khiemnguyen> pinchartl: I will try to discuss with IT. I still have some restrictions in my company. Will try to solve it. +11:16 < khiemnguyen> morimoto: you are using git-send-email, right ? +11:16 < geertu> pinchartl: yes it might (it did at Sony Europe, not Sony US) +11:16 < shimoda> khiemnguyen: i have git-send-email setting. so if you need it, please let me know :) +11:17 < khiemnguyen> shimoda: thanks. Will contact you offline. +11:17 < geertu> Thanks Khiem! +11:17 < shimoda> khiemnguyen: i got it. +11:17 < geertu> Topic 2. Handling differences between R-Car H3 ES1.x and ES2.0 +11:18 < morimoto> khiemnguyen: I never use git-send-email: I'm using Emacs+Wounderlust +11:19 < geertu> The plan has been (for a while) to use "-es1" in the compatible value, cfr. "renesas,sata-r8a7790-es1" +11:19 < geertu> Ideally, these would be added automatically to the DTB, by DT fixup code (which is WIP). +11:20 < geertu> For "renesas,sata-r8a7790-es1", this was added manually, I assume? +11:20 < pinchartl> I assume you mean r8a7795-es1 ? +11:20 < geertu> Now, it seems there are several differences between R-Car H3 ES1.x and ES2.0 +11:20 < dammsan> geertu: yes, it was an earlier trial for ES handling +11:20 < geertu> pinchartl: We don't have any r8a7795-es1 string yet. +11:21 < geertu> We started with DU and VSP +11:21 < khiemnguyen> geertu: will it be long-term solution ? +11:21 < geertu> Now we start to see differences in CPG/MSSR, PFC, ... +11:22 < geertu> khiemnguyen: In the long term, there will be ES2.0 only? +11:22 < geertu> khiemnguyen: But we may want to keep on using our ES1.x boards +11:23 < geertu> The approach we wanted to take was to focus on the most recent ES ("production") only. +11:23 < pinchartl> on the VSP and DU side there will be non-trivial differences between ES1 and ES2 and we'll need to manually update DT +11:23 < geertu> And try to fixup (preferably at runtime) for running on ES1.x. +11:24 < geertu> So for PFC, it looks like the current pfc-r8a7795 is for ES1.x only +11:24 < geertu> Due to the sheer amount of differences, I think the driver should be renamed to pfc-r8a7795-es1.c +11:25 < geertu> and a new pfc-r8a7795.c for ES2 should be added. +11:25 < neg> for PFC I think that is a good idea +11:25 < geertu> For CPG/MSSR, it's the same. +11:25 < horms> Naming convention asside, i think so too +11:25 < horms> but what if any path is there for forwards compatibility +11:26 < pinchartl> is there any estimate regarding the availability of H3 ES2.0 boards ? +11:26 < geertu> horms: if we have DT fixup, it will automatically be forweard compatible, as the DTS will only have "r8a7795" compatible values. +11:27 < horms> ok +11:27 < horms> got it +11:27 < shimoda> i have a question, how to handle if the number of channels differs between ES1 and ES2? +11:27 < geertu> horms: Only at run-time the "r8a7795-es1" would be added (or changed, for PFC and CPG/MSSR) +11:28 < geertu> shimoda: That was going to be my next point :-) +11:28 < geertu> For Multimedia, the differences seem to be in number of channels (DU) or instances (VSP), and their wiring. +11:28 < pinchartl> yes +11:28 < pinchartl> that will need to be manually changed in DT +11:28 < pinchartl> so if we need an -es1 .dtsi anyway +11:28 < geertu> _Adding_ device nodes in DT fixup code is more difficult than _removing_. +11:29 < pinchartl> is there a point in trying to fixup DT automatically at runtime ? +11:29 < geertu> So having r8a7795.dtsi match the latest revision is problematic. +11:29 < geertu> pinchartl: If it's just the number of channels, it's doable. +11:30 < geertu> If the DU<->VSP topology is too complex, it's different... +11:30 < pinchartl> geertu: it's the DU<->VSP topology that changes +11:30 < pinchartl> the number of DU channels in the same +11:30 < pinchartl> but two of them are served by the same VSP instance +11:30 < dammsan> we can also simply deprecate ES1.x DU support +11:30 < geertu> pinchartl: oh, the change in the number of DU channels is for H3<->M3-W? +11:31 < geertu> pinchartl: Can you serve the two DU channels by one VSP on ES1 too? +11:31 < geertu> (pinchartl: You have to go?) +11:33 < pinchartl> yes it's for M3 +11:33 < pinchartl> and no I can't +11:33 < pinchartl> and yes I have to go :-) +11:33 < pinchartl> sorry +11:33 < pinchartl> I'll read the log later +11:34 < geertu> Is there a document that lists the differences between H3 ES1.0, ES1.x (x > 0), and ES2.0? +11:34 < morimoto> It is difficult to understand pinchartl's yes/no, but it is not my English skill ;P +11:34 < geertu> morimoto: Yes, M3-W has less DU channels than H3 +11:35 < morimoto> geertu: let me check +11:35 < horms> s/less/fewer/ +11:35 < geertu> morimoto: No, you cannot serve the two DU channels on ES1 using one VSP +11:35 < geertu> horms: Dankuwel +11:36 < morimoto> geertu: thank you for your translation :) +11:36 < horms> geertu: sorry, that correction is hard wired into my brain through bitter experience +11:37 < geertu> uli___: You need ES checks for HDMI? +11:38 < uli___> yes +11:38 < geertu> uli___: Can it be solved through an "es1" compatible value? +11:38 < uli___> i also need to distinguish between 1.0 and 1.1... +11:38 < geertu> ... "es1.0" and "es1.1" compatible values? +11:39 < uli___> that should do +11:39 < geertu> OK, good to know. +11:39 < geertu> So I think dynamic DT fixup can work for most cases, except for DU/VSP topology +11:39 < geertu> Then, Dirk Behme is worried about boot up performance. +11:40 < morimoto> geertu: I think I can get ES diff sheet. I will send it +11:40 < geertu> Fixing DT takes time (to be measured) +11:41 < geertu> Dirk prefers an API to read PRR, and handle upon that +11:42 < geertu> Or we can use soc_device_register() (see include/linux/sys_soc.h) +11:43 < geertu> Arnd posted a patch to add soc_device_match(), which can match against SoC-specific revision wildcards. +11:44 < geertu> But I take it all of you are slowing falling asleep? ;-) +11:44 < uli___> to me, that sounds better than the other approaches discussed so far +11:45 < geertu> Which one sounds better? PRR API? soc_device_match()? +11:45 < uli___> the latter +11:46 < geertu> We may still need DT fixup for backwards compatibility (add RST and APMU device nodes) +11:46 < shimoda> i didn't know the drivers/base/soc.c, and it seems very simple +11:46 < geertu> and I had a wild idea of using DT fixup to add all SoC-specific compatible values, so we can share more .dtsi +11:47 < uli___> as for the boot-up delay, what order of magnitude are we talking here? +11:48 < geertu> To be measured... +11:49 < uli___> ah, ok +11:49 < geertu> It also depends at which phase of the boot we do it. +11:49 < dammsan> i just don't want to add a new special API that we are the only users of +11:49 < geertu> For APMU devices nodes, it needs to be done right after unflatten, which is before we have kmalloc() :-( +11:51 < dammsan> soc_device_match() may not be so bad +11:51 < geertu> dammsan: So you also like nvmem API for MODEMR? +11:51 < dammsan> not so much +11:51 < dammsan> i just dislike the PRR proposal by Dirk +11:51 < dammsan> it is like looking at vxworks code +11:52 < dammsan> it also goes against being standard +11:52 < neg> I'm a bit scared of DT fixups, but trust your judgemnt that it won't eat my dog :-) +11:52 < dammsan> and following simple accepted APIs +11:52 < geertu> Bonus is you will get the ES version somewhere in /proc or /sys ;-) +11:52 < dammsan> also, if DT is so slow, why don't we have any numbers yet? +11:52 < dammsan> hehe +11:53 < geertu> dammsan: Nobody does DT fixup +11:53 < dammsan> i know +11:53 < dammsan> but at least proposing a general purpose way of doing things +11:53 < dammsan> is much better than cooking up your local API just to be used by a couple hidden away drivers +11:54 < geertu> OK, will try the soc_device_match() thingy +11:54 < dammsan> so i think it is great that you are proposing the DT fixups +11:54 < dammsan> or whichever new standard you are proposing +11:54 < dammsan> as long it is not specific to our SoC +11:55 < dammsan> looking forward to see your proposal +11:56 < geertu> If we don't do DT fixup for ESx.y, we will keep single pfc-r8a7795 and r8a7795-cpg-mssr drivers that do their own ES check through soc_device_match()? +11:59 < horms> I'm unclear on what soc_device_match() would match on +12:00 < geertu> On the revision string in include/linux/sys_soc.h:soc_device_attribute +12:01 < shimoda> I'm afraid again but how to handle the number of channels differs by soc_device_match() API? +12:02 < shimoda> for example, es1.1: usb3 2ch, usb2 3ch --> es2.0: usb3 1ch, usb2 4ch +12:02 < geertu> shimoda: For those things we need a different solution +12:02 < geertu> H3 ES2.0 is really a different SoC +12:03 < shimoda> geertu: i understood it. thanks! +12:05 < geertu> Guys, I'm not gonna hold you from whatever any more. +12:05 < geertu> Thanks for joining the 25th edition! +12:05 < horms> thanks, look forward to the 26th! +12:05 < neg> thanks all +12:06 < uli___> bye +12:06 < neg> geertu: I was a bit confused by this meeting inviation. Do you want a summary of the A), B) and C) items in the mail or just updates to periperi lit items? +12:07 -!- horms [~horms@217.111.208.18] has quit [Read error: Connection reset by peer] +12:07 < geertu> neg: Just updates to the todos, like Wolfram commented a while ago ;) +12:07 -!- horms [~horms@217.111.208.18] has joined #periperi +12:11 < shimoda> thanks all! bye! +12:11 -!- shimoda [~shimoda@relprex1.renesas.com] has quit [Quit: WeeChat 0.4.2] +12:12 < morimoto> geertu: Can we have this discussion (= how to handle ES version) on ELCE timing ? +12:13 < geertu> morimoto: Sure +12:13 < morimoto> Thanks +12:13 < morimoto> I added its page on +12:13 < morimoto> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-10 +12:13 < geertu> Thanks +12:14 < morimoto> Bye |