wiki: Porting wiki: Porting Chat Log

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 389 insertions, 0 deletions

diff --git a/wiki/Chat_log/20151106-core-chatlog b/wiki/Chat_log/20151106-core-chatlog
new file mode 100644
index 0000000..d3ad5ad
--- /dev/null
+++ b/wiki/Chat_log/20151106-core-chatlog
@@ -0,0 +1,389 @@
+Core-chat-meeting-2015-11-06
+
+10:04 < geertu> Agenda:
+10:04 < geertu> 1. Upcoming Gen3 development for the Core group,
+10:04 < geertu> 2. Gen3 integration - ARCH_R8A7795 / ARCH_RENESAS - serial0:115200n8 - GIC/GICH/GICV
+10:04 < geertu> 3. Status check for tasks from last meeting - what is remaining?
+10:04 < geertu> Topic 1: Upcoming Gen3 development for the Core group
+10:04 < horms> I can also speak to some gen2 ingegration work if there is time
+10:05 < geertu> OK, let's cover that with Topic 2.
+10:05 < horms> With regards to topic 1, Morimiti-san, do you want to talk about sound?
+10:05 < horms> wow, super bad typing. I meant morimoto`
+10:06  * geertu thought it was modern Greek where all vowels became 'i'
+10:06 < morimoto`> I posted sound patch-set to SH/ARM ML
+10:06 < horms> ok, just now?
+10:06 < morimoto`> It might have compile issue
+10:06 < horms> ok, we can handle that on the ML. thanks for your emails earlier today
+10:07 < morimoto`> But it seems nothing happen on latest ARM branch (?)
+10:07 < morimoto`> np
+10:07 < morimoto`> My issue is that there is DMA_OF wrong dependency issue
+10:07 < morimoto`> I already posted fixup patches to DMA ML
+10:07 < horms> i think the summary for the gruop is that sound for gen3 is moving forwards, but we have some tedious dependencies in the short term
+10:08 < morimoto`> Vinod accepted it, but he decided it goes to topic branch instead of fixup branch
+10:08 < horms> bother
+10:08 < horms> can we ask him to reconsider?
+10:09 < morimoto`> Him = Vinod ?
+10:09 < geertu> It causes build errors, right?
+10:09 < horms> Yes, Vinod.
+10:09 < morimoto`> build error will happen if
+10:09 < morimoto`> 1) .config has CONFIG_OF, but doesn't have DMA_OF
+10:09 < morimoto`> but it seems latest branch defconfig have both.
+10:10 < morimoto`> So, no build error I think
+10:10 < morimoto`> But, I don't know which branch goes to Linus/master
+10:10 < horms> not for the defconfig at least
+10:10 < geertu> Is this topic branch queued for v4.4 or for v4.5?
+10:10 < horms> probably randconfig can find something
+10:11 < morimoto`> I believe it goes to v4.4
+10:11 < horms> ok, so the breakage was added in v4.4 (pre-rc1) and the fix will probably make it to v4.4?
+10:11 < geertu> So it will be upstream RSN?
+10:12 < morimoto`> I believe so
+10:13 < horms> It sounds to me that we can make a working system using defconfig and the non-defconfig case should be resolved in the not to distant future. So I think we are in good shape.
+10:13 < geertu> So what's the problem? A small time window for a possible build failure of randconfig?
+10:14 < dammsan> so it seems
+10:15 < horms> I think we can move on
+10:15 < geertu> yep.
+10:15 < geertu> No more upcoming Gen3 development?
+10:16 < geertu> s/more/other/
+10:16 < dammsan> i'm dealing with IPMMU at the moment
+10:16 < pinchartl> geertu: not for core on my side. plenty of multimedia development though :-)
+10:17 < dammsan> FYI, to use the IPMMU the boot loader stack needs to be updated =\
+10:18 < dammsan> i'll tackle IRQC some time in the not so distant future
+10:18 < geertu> hooray
+10:18 < pinchartl> dammsan: what's wrong with the boot loader ?
+10:18 < dammsan> it may be easier to phrase the question the other way around
+10:18 < geertu> what's wrong with the ipmmu?
+10:19 < dammsan> for the IPMMU case, some piece of software is not letting through MMU interrupts
+10:19 < dammsan> PMB interrupts are let through though
+10:19 < geertu> (secure) firmware?
+10:19 < dammsan> that's my bet
+10:19 < pinchartl> nice...
+10:19 < dammsan> i now have some code that can get interrupts
+10:19 < dammsan> using more recent boot software
+10:20 < dammsan> in such case DEBUG1 stops working too
+10:20 < dammsan> so i've poked around with the loop back adapter as a plan C
+10:20 < dammsan> it is a bit messy
+10:20 < dammsan> expect IPMMU to take some time
+10:21 < geertu> So that explains your interest in EXIO (H)SCIF ;-)
+10:21 < horms> dammsan: do you have a fire extinguisher in your lab?
+10:21 < dammsan> in case the printer is on fire? =)
+10:21 < dammsan> the fans from the 2 salvator-x board should boost the fire well =)
+10:21 < horms> thats not the use case i had in mind, but yes, in case of that too
+10:22 < dammsan> if you have trouble with some hardware consider upgrading the boot loader software
+10:22 < dammsan> but it is a PITA so i don't recommend it unless it is absolutely necessary
+10:23 < dammsan> you will notice if you are blocked on that
+10:23 < dammsan> let me know if so
+10:24 < dammsan> no other activities planned here
+10:25 < shimoda> dammsan: I guess if we have to use memory more (more 1GB), we have to upgrade the boot loader
+10:25 < dammsan> yeah
+10:25 < dammsan> SMP may need some help too
+10:26 < shimoda> I think so
+10:26 < dammsan> we should consider how to handle caches
+10:26 < dammsan> both on gen2 and gen3
+10:27 < dammsan> ideally before enabling SMP in my opinion
+10:27 < dammsan> what does the mighty core group leader say?
+10:27 < geertu> I have patches to describe the caches, as part of the SYSC PM Domain work
+10:28 < geertu> That was a bit put aside due to the CPG rework
+10:28 < dammsan> completely understandable
+10:28 < dammsan> seems the bindings are in now
+10:28 < geertu> Yes, CPG/MSSR bindings are in.
+10:28 < geertu> Which brings us to Topic. Gen3 integration
+10:28 < dammsan> very nice!
+10:29 < horms> ok, so there are a few outstanding questions from the postings of v11 and v12 of the basic patchset; which I have been handling since ELCE
+10:29 < geertu> Simon wanted to discuss 4 integration things
+10:30 < geertu> a. ARCH_R8A7795 (and ARCH_RENESAS?)
+10:30 < horms> overall I'm tempted to label them as bikeshedding. But none the less I7d like to get some consensus amongst us before moving
+10:30 < dammsan> i agree and i agree =)
+10:30 < geertu> Summarized: Catalin wants to get rid of SoC-specific Kconfig options. "Use SoC+driver0specific Kconfig options
+10:31 < horms> See: http://www.spinics.net/lists/arm-kernel/msg457009.html
+10:31 < horms> my reading is that he asked if we need ARCH_R8A7795
+10:31 < geertu> Personally, ... ah, your link covers that
+10:31 < horms> and given the way pfc and cpg work
+10:31 < horms> i think the answer is yes, we need it
+10:32 < geertu> Perhaps they like it more if we call it CONFIG_QUIRK_R8A7795? ;-)
+10:32 < pinchartl> we only need it if we want to keep the kernel size reasonable
+10:32 < geertu> yes
+10:32 < horms> yes
+10:32 < pinchartl> and that's a reasonable thing to do :-)
+10:32 < dammsan> the newer boot loader has reduced the amount of memory =)
+10:32 < geertu> So I like hiding it under CONFIG_EXPERT
+10:32 < dammsan> geertu: i like that too
+10:32 < horms> sure, that sounds fine to me
+10:33 < horms> will you replay to Catalin or should I (next week)?
+10:33 < dammsan> horms: i prefer if you can come to an agreement with him
+10:34 < horms> sure, will do
+10:34 < dammsan> thanks
+10:34 < horms> shall we move to b.?
+10:34 < geertu> I'd ike to ask about ARCH_RENESAS
+10:34 < horms> sure
+10:34 < horms> this serves two purposes.
+10:34 < geertu> So the patch description mentioned it may also apply to SH
+10:35 < horms> the technical one I tried to describe on the ML
+10:35 < horms> and also a non-techincal one: a red-herring for the ARM-SoC maintainers desire to see cleanups
+10:35 < horms> yes, it did mention that
+10:35 < geertu> There's lots of overlap between arm64 and arm32
+10:35 < geertu> less between arm32 and SH
+10:35 < horms> yes
+10:35 < horms> the reason i mentioned it is to cover that overlap
+10:36 < geertu> even less between SH and H8 (e.g. SCI)
+10:36 < horms> but perhaps it not needed
+10:36 < geertu> any overlap with m32r?
+10:36 < horms> ideally I'd like to see SHMOBILE disapear from drivers used by arm socs
+10:36 < horms> i didn't investigate deeply, but grep didn't show any
+10:36 < horms> the thing is that r-car, which is the focus for renesas, is neither SH nor mobile
+10:37 < geertu> So for now the "RENESAS" flag would cover Renesas arm32 and arm64 SoCs
+10:37 < horms> yes
+10:37 < horms> and if that is sufficient that SHMOBILE is not used by those SoCs then the work can stop there
+10:37 < horms> or it can keep going if there is some reason to
+10:37 < geertu> Fine for me. But please drop the reference to SH?
+10:38 < horms> Sure, can do
+10:38 < horms> sorry for the confusion that generated
+10:38 < geertu> NP
+10:38 < horms> shall we move to c.?
+10:39 < geertu> Subtopic b. serial0:115200n8
+10:39 < horms> See: http://www.spinics.net/lists/linux-sh/msg46481.html
+10:39 < horms> I'm inclinded to not add :115200n8. But I'd value your opinion.
+10:40 < geertu> As DT describes "the hardware" (chosen describes configuration), I don't mind adding it.
+10:40 < geertu> There's plenty of opportunity to fix this for v4.5
+10:40 < horms> sure, that sounds reasonable
+10:40 < horms> but what about earlycon. do we care? can it be compatibile?
+10:41 < geertu> As the standard console parses stdout-patch correctly, I think earlycon should follow suit
+10:41 < horms> ok, thats reasonable
+10:41 < dammsan> sounds reasonable
+10:41 < geertu> I'm still a bit puzzled by earlycon on arm32.
+10:41 < geertu> Apparently it works on some platforms.
+10:41 < horms> i'll see about adding :115200n8 to v13
+10:41 < horms> what about gen2. do you want to talk about that?
+10:41 < geertu> yes
+10:41 < horms> s/gen2/32-bit arm/
+10:42 < geertu> Earlycon is very valuable: it's intended to replace debug_ll ,which does not exist anymore on arm64
+10:42 < horms> so i'm ok with updating our 32-bit SoCs. but is there a backwards compatibility issue?
+10:42 < geertu> It helped me a lot debugging the L1_CACHE_BYTES issue on Salvator-X
+10:42 < dammsan> i agree that early output is very valuable
+10:42 < horms> i definately don't want to stand in the way of making useful tools work :)
+10:42 < geertu> I don't see a backwards compatibility issue
+10:43 < horms> ok, shall we move forwards on the 32-bit side too?
+10:43 < geertu> For arm32, I think we need a "JTAG expert" to look into it
+10:43 < horms> earlycon?
+10:43 < geertu> yes
+10:43 < horms> ok, but that is orthogonal to your proposed dts change, right?
+10:44 < geertu> yes.
+10:44 < horms> ok, got it. feel free to send that patch any time. if its rough i can clean it up.
+10:44 < geertu> earlycon does an early mapping of the serial port. Apparently it maps something (no crash), but nothing is output on the serial potty
+10:44 < geertu> s/potty/poty/
+10:44 < geertu> s/potty/port/
+10:44 < horms> with regards to jtag, perhaps morimoto-san could help out?
+10:44 < geertu> or Ulrich?
+10:45 < uli___> what exactly is the issue there?
+10:46 < geertu> earlycon doesn't output anything on R-Car Gen2 (and other "shmobile", IIRC)
+10:46 < dammsan> we had a different implementation for non-multiplatform earlier
+10:46 < geertu> Until recently, it didn't work at all, as arm32 didn't have early fixmap support
+10:46 < geertu> earlyprintk?
+10:46 < dammsan> yeah
+10:47 < uli___> ah, i see.  i remember using that, so i was wondering...
+10:47 < uli___> which platforms are known to be broken?
+10:47 < uli___> boards, i mean
+10:47 < dammsan> all?
+10:47 < pinchartl> do we need earlycon or is earlyprintk enough ?
+10:47 < geertu> earlycon is platform-agnostic
+10:48 < dammsan> earlyprintk used to be compatibile with SH
+10:48 < geertu> and The Way Forward(tm)
+10:48 < geertu> I think it's also "more early" than earlyprintk
+10:48 < dammsan> but then earlycon came around =)
+10:48 < horms> why use something that works when you can invent something new to spend years fixing?
+10:48 < geertu> On last renesas-drivers, applying Sata-san's SCIF EARLYCON patch should give you working earlycon on Salvator-X
+10:48 < geertu> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364178.html
+10:49 < pinchartl> which of the two is the one that requires the assembly header with a couple of serial port functions ?
+10:49 < geertu> debug_ll, which is something different
+10:49 < geertu> no more debug_ll in arm64
+10:49 < geertu> earlycon uses chosen/stdout-path
+10:49 < geertu> so it's compatible with real multi-platform kernels and multi-plaform debugging
+10:50 < dammsan> good
+10:50 < geertu> So you have debug_ll, earlyprintk, and and earlycon
+10:50 < pinchartl> ok
+10:50 < pinchartl> sounds so simple :-)
+10:50 < geertu> Going from most-platform dependent to platform-agnostic
+10:50 < geertu> s/Sata-san/Sato-san/ (forgive today's typing)
+10:51 < geertu> Just add "earlycon" to the kernel command line, and you get early debugging output on about everything 
+10:52 < dammsan> nice
+10:52 < geertu> well, that's the  idea
+10:52 < dammsan> i suppose we need clocks relatively earl then
+10:52 < dammsan> or maybe we can make assumptions
+10:52 < horms> Nice, we can add it to dt and be back to where we were with earlyprintk on our 32-bit SoCs before DT came along :)
+10:52 < geertu> No, it still depends on the bootloader to set up the serial port
+10:53 < dammsan> gotcha
+10:53 < geertu> But selection of the serial port is now done in "the same way" as the regular serial console
+10:53 < geertu> i.e. chosen/stdout-path
+10:54 < pinchartl> geertu: how is the serial port driver involved in earlycon ?
+10:54 < morimoto`> (dammsan goes to other Renesas meeting)
+10:54 < pinchartl> tell me there's no early platform device...
+10:55 < geertu> OF_EARLYCON_DECLARE
+10:55 < pinchartl> I should have guessed that :-/
+10:55 < geertu> https://progressive-comp.com/?l=linux-sh&m=143366932126892&w=2
+10:57 < geertu> Subtopic c. GIC/GICH/GICV
+10:57 < horms> BTW, do you know who Sato-san is?
+10:58 < geertu> The h8300 guy
+10:58 < horms> c. is here http://www.spinics.net/lists/arm-kernel/msg457615.html
+10:58 < horms> ok, makes sense
+10:58 < geertu> who's using earlycon on h8 ;-)
+10:58 < geertu> back where it all started?
+10:58 < horms> so regarding GIC
+10:58 < horms> do we need to do anything?
+10:59 < geertu> Are the virtualiation regs documented in later versions (>0.5) of the datasheet?
+10:59 < horms> I'm unsure. Shall we speculate and check later?
+11:00 < horms> perhaps morimoto-san` or shimoda-san know
+11:01 < shimoda> i greped the datasheet of rev0.5, "virtualization" is only in overview section
+11:01 < shimoda> it is a function of CA57
+11:02 < shimoda> so, i guess it is described in a documentation of ARM
+11:02 < geertu> But the actual addresses of the register banks of the GIC are SoC-specific, right?
+11:02 < geertu> And the Gen3 datasheet only describes banks 1 and 2
+11:05 < shimoda> which page does it described?
+11:05 < shimoda> about the bank
+11:05 < geertu> 12A3
+11:06 < geertu> 533
+11:07 < geertu> INTC-AP H'F102 0000 √ √
+11:07 < geertu> H'F101 0000 √ √
+11:07 < geertu> CPU-IF
+11:07 < geertu> INTC-AP
+11:07 < geertu> ar
+11:07 < geertu> Distributor-IF
+11:07 < geertu> Someone edited the table, so Copy-'n-paste no longer grabs the cells in the "normal" order
+11:08 < shimoda> thank you, I found it
+11:10 < shimoda> and these CPU-IF and Distributor-IF are written into r8a7795.dtsi
+11:11 < morimoto`> geertu: sorry what is your question/concern ? it should have more information ?
+11:11 -!- shimoda [~shimoda@relprex2.renesas.com] has quit [Quit: WeeChat 0.4.2]
+11:11 < geertu> Documentation/devicetree/bindings/arm/gic.txt
+11:12 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi
+11:12 < geertu> GIC virtualization extensions (VGIC) means 2 more register bankds
+11:12 < geertu> s/bankds/banks/
+11:12 < geertu> Documentation/devicetree/bindings/arm/gic.txt
+11:15 < morimoto`> Does your question is that it should have bank 3, and 4 ?
+11:17 < geertu> Yes, according to Mark Rutland
+11:17 < geertu> Unless the H3 GIC doesn't have virtualization extensions, of course ;-)
+11:18 < horms> do we also need to know the maintenance irq?
+11:18 < geertu> I think so
+11:19 < morimoto`> Actually, today we got errata sheet, and I checked it now. but it doesn't include this.
+11:19 < morimoto`> So, I will ask to HW/Manual guys
+11:19 < horms> thanks
+11:20 < horms> it seems to me that we re blocking on this one
+11:20 < geertu> yes
+11:20 < horms> geertu is that your understanding?
+11:20 < geertu> thanks for asking
+11:20 < horms> ok
+11:20 < morimoto`> Can I confirm ? bank 3/4 are because of 4 cpu ?
+11:20 < geertu> so let's leave the dtsi like it is for now
+11:20 < horms> i will likely not post v13 in the near future
+11:20 < geertu> morimoto: no, because of virtualization extensions
+11:20 < horms> unless there is a pressing need for it
+11:21 < geertu> subtopic d. Gen2 integration
+11:21 < morimoto`> OK, I see. thanks
+11:21 < horms> ok, this i think we sould not spend much time on
+11:21 < horms> I expect that in general it will be a topic that would be well named after a book I recently purchased "Argument Without End".
+11:22 < horms> The quick summary is that Magnus has asked me to make sure we have more uniform coverage on the integration side for our various (32-bit) socs
+11:22 < horms> I have started by focusing on R-Car Gen 2
+11:22 < horms> and the thermal patch I sent earlier today is the first cab of the rank
+11:23 < horms> in short lager and koelsch seem to be in pretty good shape
+11:23 < horms> but it gets much thinner on the ground when looking at the other SoCs and boards
+11:23 < geertu> It would be good if we could "share" more dtsis
+11:24 < horms> yes, its quite repeditive
+11:25 < horms> but the current dts files distinguish between the different socs in terms of defines (easy to resolve I suppose) and per-soc bindings (see title of book above!)
+11:25 < horms> perhaps the dts files can be generated some how
+11:26 < horms> anyway, i just wanted to mention i'm putting some energy into that
+11:26 < geertu> Having more docs (incl. schematics) could help, too.
+11:26 < pinchartl> horms: I'll refrain to comment on that last point :-)
+11:27 < geertu> I can just guess that e.g. goose is similar to koelsch
+11:27 < horms> i managed to get docs from morimoto-san earlier today
+11:27 < horms> so i am guessing less now
+11:27 < horms> there is also the gen2 bsp
+11:28 < geertu> OK
+11:28 < horms> in any case, i suggest we move on and come back to this another time: its likely to be around for a while and its very non-urgent
+11:28 < geertu> We're running out of time. Can we continue
+11:28 < geertu> ok
+11:28 < geertu> Topic 3. Status check for tasks from last meeting - what is remaining?
+11:29 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list
+11:29 < geertu> Done:
+11:29 < geertu>         pfc,v4.4,Add r8a7795 support
+11:29 < geertu>         r8a7795,v4.4,Add gpio nodes to DT
+11:29 < geertu> Ack's wanted:
+11:29 < geertu> pfc,v4.4,Improve documentation
+11:29 < geertu> (and a few more pfc patches)
+11:30 < geertu> Now Simon is here: generic,v4.4,Propose API to obtain mode pin values in a generic way
+11:31 < horms> yes, i think the main issue there is how to handle initcalls (or not)
+11:34 < horms> http://www.spinics.net/lists/linux-sh/msg46246.html
+11:34 < horms> From my pov the *_OF_DECLARE approach seems to give the cleanest code
+11:34 < pinchartl> horms: I agree with you
+11:35 < pinchartl> I dislike *_OF_DECLARE though
+11:35 < pinchartl> as it's an initcall-like hack
+11:35 < pinchartl> but I don't have a better solution at the moment
+11:35 < geertu> And the person who encounters dependency issues has to fix it herself?
+11:35 < horms> right, it seems to be faustian pact
+11:36 < horms> the other approach was to allow users to directly initialse things if they are running before initcalls would have kicked in
+11:36 < horms> its not so clean code
+11:36 < horms> but its probably harder to get wrong
+11:36 < horms> for gen2 the initcall bit might be omitted entirely
+11:37 < horms> unless we figure out a way that it doesn't need the modepin before initcalls
+11:37 < horms> are run
+11:38 < geertu> OK, let's post it to a broader audience for discussion
+11:38 < geertu> Or is that a bad idea during the merge window?
+11:38 < horms> i don't see any problem with posting RFCs during the merge window
+11:38 < horms> do you mean that I should see linux-arm-kernel?
+11:39 < geertu> And if we delay, it may be too late for v4.5
+11:39 < geertu> linux-arm-kernel and linux-kernel
+11:39 < horms> ok
+11:39 < geertu> perhaps Jon Corbet too, so it ends up on lwn.net?
+11:39 < horms> i'll fix up the obvious problems with v1 but not convert it to *_OF_DECLARE
+11:40 < horms> and probably add some text about *_OF_DECLARE being a possibility
+11:40 < horms> perhaps if its going to lkml then wating for rc1 would be prudent
+11:40 < horms> we don't want it to get shot down before is even been thought about
+11:40 < geertu> Clearly mark it RFC
+11:41 < horms> ok
+11:41 < geertu> People don't (ordinarily) read lkml anyway
+11:41 < horms> true
+11:41 < horms> pinchartl: is the above reasonable from your pov?
+11:42 < horms> I guess if its not he can ping me :)
+11:43 < pinchartl> yes it's fine
+11:43 < horms> thanks
+11:43 < pinchartl> maybe you could mention *_OF_DECLARE as an option in the cover letter ?
+11:43 < horms> btw, I would not be upset if you wanted to take your baby back under your wing :)
+11:43 < horms> yes, that is what I had in mind
+11:43 < pinchartl> I wish I had time to do that :-)
+11:44 < horms> (does anyone read cover letters?)
+11:44 < horms> understood. its an open offer
+11:44 < pinchartl> thanks :-)
+11:44 < horms> ok, i think we can move on
+11:44 < horms> sorry for pushing things over time
+11:44 < geertu> Any other topics?
+11:45 < horms> not from me
+11:45 < geertu> I have: [Linux Kernel development - Feature #XX] emails
+11:45 < geertu> So yes, I'm receiving them
+11:46 < horms> Was ist das?
+11:46 < shimoda> geertu: not from me
+11:46  * uli___ checks the universal translator switches
+11:47 < geertu> uli: Don't speak German anymore?
+11:47 < geertu> They are sent by oss-admin@lm.renesas.com
+11:48 < horms> ok. do they relate to the todo lists, redmine, or something else?
+11:48 < geertu> From Redmine. Am I the only one who's receiving them?
+11:48 < horms> (obviously I haven't seen one)
+11:48 < uli___> me neither
+11:48 < pinchartl> neither have I
+11:48 < geertu> OK, will forward one to periperi
+11:49 < horms> good idea
+11:49 < horms> i tweaked periperi so mainlan no longer enforces a message size limit
+11:50 < horms> As magnus kept hitting it.
+11:50 < horms> But the mail server istelf still has a limit, somwhere between 10 & 20Mb iirc
+11:50 < horms> fwiw, gmail has a similar message size limit
+11:53 < geertu> I guess that's why I haven't received new datasheets? ;-)
+11:53 < geertu> No more topics?
+11:53 < horms> I don't think it is related
+11:53 < morimoto`> I got errata sheet form manual guys. do you want to have it ?
+11:54 < morimoto`> for v0.5 datasheet
+11:54 < geertu> yes please
+11:54 < pinchartl> yes please !
+11:54 < shimoda> I heard  new datasheet will come at early next year, I'm surprized
+11:54 < morimoto`> OK. I will Me -> Jinso -> EuroPeri
+11:54 < morimoto`> s/I/It/g
+11:55 < morimoto`> and it will happen next week.
+11:56 < geertu> thx!
+11:56 < horms> likewise
+11:57 < morimoto`> No more topic from me
+11:57 < geertu> ok, then we're finished.
+11:57 < geertu> Thanks for joining!