1 files changed, 223 insertions, 0 deletions
diff --git a/wiki/Chat_log/20161108-core-chatlog b/wiki/Chat_log/20161108-core-chatlog
new file mode 100644
index 0000000..756c914
--- /dev/null
+++ b/wiki/Chat_log/20161108-core-chatlog
@@ -0,0 +1,223 @@
+Core-chat-meeting-2016-11-08
+
+09:07 < geertu> Welcome to today's Core Group Chat
+09:07 < geertu> ... and try to keep it short ;-)
+09:07 < geertu> Agenda: 
+09:07 < geertu> 1. Status updates
+09:07 < geertu> 2. Inquiries from Tokyo
+09:08 < geertu> Topic 1. Status updates
+09:08 < geertu> First is Simon
+09:08 < horms> TODO Update is NULL for me
+09:08 < horms> Status:
+09:08 < horms> A) What have I done since last time
+09:08 < horms> * No core tasks at this time
+09:08 < horms> B) What I plan to do till next time
+09:08 < horms> * Land Geert's RST patches in reness tree
+09:08 < horms> C) Problems I have currently
+09:08 < horms> * 16Mbyte kernels: Do we have a timeframe for firmware upgrade?
+09:08 < horms> * Gen2 Suspend 2 Ram: What are the next steps (same as last time)
+09:08 < horms> * Access to [MH]ULCB documentation and hw
+09:08 < horms> -- end --
+09:08 < geertu> s/Gen2/Gen3/?
+09:09 < geertu> 16Mbyte kernels: any takers?
+09:09 < horms> Same error as last time; yes, gen3
+09:09 < horms> Probably Khiem or Shimoda-san are the best bet there
+09:10 < shimoda> about 16Mbyte kernel, coming soon
+09:10 < horms> superb
+09:11 < shimoda> https://github.com/renesas-rcar/u-boot/commits/v2015.04/rcar-3.4.x
+09:11 < shimoda> https://github.com/renesas-rcar/arm-trusted-firmware/commit/c2f9fc9f1324d429decd2b2810fd0c0bde577fd7
+09:11 < shimoda> they seem -rc
+09:12 < shimoda> but
+09:12 < horms> Ok, so we might see this by the end of the year?
+09:12 < shimoda> horms: yes. perhaps -rc is removed in end of this month I guess
+09:12 < horms> ok, great. thanks for the update
+09:13 < geertu> Shimoda: Does that firmware enable Lossy Decomp?
+09:14 < shimoda> geertu: this should be counfigureble
+09:14 < shimoda> so we can disable it
+09:14 < morimoto> Basically, Lossy will be enable if we selected MultiMedia package on Yocto
+09:14 < morimoto> And I don't select it :P
+09:14 < geertu> OK
+09:16 < geertu> Suspend 2 Ram: I guess we should try Suspend to Idle?
+09:16 < geertu> https://www.linaro.org/blog/suspend-to-idle/
+09:16 < geertu> See also Laurent's write-up of his discussion about this topic at LPC
+09:16 < horms> ok, i saw pinchartl's email
+09:18 < geertu> Access to [MH]ULCB documentation and hw: Morimoto-san?
+09:18 < geertu> H3ULCB docs we already have
+09:19 < horms> ok, i seem to be missing them for some reason
+09:19 < horms> but not to worry
+09:19 < morimoto> ulcb hw access will be remote
+09:19 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/H3_ULCB
+09:21 < horms> thanks
+09:21 < geertu> Morimoto-san: Can we have docs for M3ULCB, too?
+09:21 < morimoto> No, at this point
+09:21 < morimoto> but will send to you ASAP
+09:22 < horms> thanks
+09:22 < geertu> thx
+09:22 < geertu> Next is Shimoda-san
+09:23 < shimoda> a) wrote Lossy infor in eLinux
+09:23 < shimoda> b) and c) nothing core tasks to me
+09:23 < shimoda> -- end --
+09:23 < geertu> Thanks, Shimoda-san
+09:23 < geertu> Next is Niklas
+09:24 < neg> A)
+09:24 < neg>  - Fixed review comments on H3 PFC drive-strengh
+09:24 < neg>  - PFC fixups in regard to bias handling
+09:24 < neg>  - Started to work on drive-strength and bias handling for r8a7796
+09:24 < neg> B)
+09:24 < neg>  - Finish r8a7796 PFC work
+09:24 < neg>  - Send v2 of PFC bias fixups
+09:24 < neg> C) None
+09:24 < neg> EOT
+09:25 < geertu> Thanks Niklas
+09:25 < geertu> Next is Morimoto-san
+09:25 < morimoto> geertu: (There is no difference between H3/M3 ulcb board. The difference is only SoC)
+09:25 < morimoto> A) What I have done since last time
+09:25 < morimoto>    I'm preparing board export paper work for new guys
+09:25 < morimoto> B) What I plan to do till next time
+09:25 < morimoto>    No Core task
+09:26 < morimoto> C) Problems I have currently
+09:26 < morimoto>    Our team's server HDD has gone (= not relateed to PeriPeri :)
+09:26 < morimoto>  
+09:26 < morimoto> please ignore C)
+09:26 < geertu> morimoto: Thanks for confirming (we already assumed that was the case ;-)
+09:26 < horms> did someone leave the HDD on the bus?
+09:26 < geertu> I hope there using LVM-CRYPT
+09:26 < morimoto> This HDD is very local server :) no problem
+09:27 < horms> :)
+09:27 < geertu> s/there/they're/
+09:27 < geertu> Thanks Morimoto-san
+09:27 < geertu> Next is Geert
+09:27 < geertu> A) What have I done since last time
+09:28 < geertu>   - Sent out v2 of SoC identifaction and ESx.y handling
+09:28 < geertu>       - Waiting for response from Arnd to create shared branch with
+09:28 < geertu>         soc_device_match()
+09:28 < geertu>   - Sent out v1 of 64-bit memory with M3-W Ethernet
+09:28 < geertu>       - 64-bit memory is silently enabled and already working
+09:28 < geertu>       - Added swiotlb=nobounce to debug
+09:28 < geertu>       - SYS-DMAC needs 40-bit DMA mask => works
+09:28 < geertu>       - RAVB DMAC supports 32-bit memory only, needs IPMMU => works
+09:28 < geertu>         initially, then fails
+09:28 < geertu>   - Sent clock and pinctrl pull requests for v4.10
+09:28 < geertu> B) What I plan to do till next time
+09:28 < geertu>   - Get SoC identifaction and ESx.y handling accepted
+09:28 < geertu>   - Queue up RZ/G1M and RZ/G1E clock drivers
+09:28 < geertu>   - Coerce Simon into taking all MODEMR related patches
+09:28 < geertu>   C) Problems I have currently
+09:28 < geertu>   - Too many dependencies between patches and patch series
+09:28 < geertu> (but it's getting better, slowly)
+09:28 < geertu> --- EOT ---
+09:29 < horms> geertu: let me know if/when/how i cn help with C)
+09:29 < geertu> So IPMMU for RAVB seems to work a bit.
+09:29 < geertu> Unfortunately the IPMMU expert is missing (JP lessons?)
+09:30 < geertu> As Uli, Magnus, Laurent, and Khiem are missing, Topic 1 is finished
+09:30 < geertu> Topic 2. Inquiries from Tokyo
+09:30 < geertu> A) H3 PFC from BSP team.
+09:30 < geertu> Some definitions will be conflict between H3 ES1.x and ES2.0
+09:30 < geertu> BSP team would like to know how to handle this (if we use single pfc-r8a7795.c).
+09:31 < geertu> IIUC, H3 ES2.0 PFC is almost identical to M3-W PFC.
+09:31 < geertu> So can't we use pfc-r8a7796.c for both (with some runtime table patching)?
+09:33 < morimoto> And I got 2 request from BSP team for renesas-drivers + v4.9
+09:33 < morimoto> 1) HDMI out plan (= Geert ?)
+09:33 < morimoto> 2) m3ulcb plan (= Simon ?)
+09:33 < morimoto>  
+09:33 < geertu> Any comments on H3 ES2 PFC?
+09:34 < geertu> Does it make sense?
+09:35 < geertu> 1) HDMI out plan
+09:35 < neg> I think so, so far I have only discoverd veary small diffs when looking at drive-strength and bias settings
+09:35 < morimoto> geertu: Does this "runtime table patching" means compatible with "-esxx" ?
+09:35 < shimoda> geertu: thank you for the comment about the PFC
+09:35 < geertu> Isn't this something for MultiMedia? If I receive a pull request, I can include it
+09:36 < shimoda> BSP team are also think about it (use pfc-r8a7796 or separate files for es1.x and es2.0)
+09:36 < horms> 2) m3ulcb plan
+09:36 < geertu> No, soc_device_match(r8a7795es1)
+09:36 < horms> I merged most of the patches from Vladimir yesterday
+09:36 < geertu> Cfr. "[RFC] pinctrl: sh-pfc: r8a7795: Add PoC support for R-Car H3 ES2.0"
+09:36 < horms> so they should appear in renesas-drivers soon
+09:37 < horms> I did not merge the SDHI enablement patches but I expect to do so soon as the update requested is small at this time
+09:37 < morimoto> geertu: Ahh OK. make sense. But can use "-esxx" compatible too, right ?
+09:38 < morimoto> horms: thanks !
+09:38 < geertu> morimoto: yes, we could use renesas,pfc-r8a7795-es2 too, as we need a separate DTS anyway
+09:39 < geertu> Recently Mark Rutland said:
+09:39 < geertu> "If it affects the programming model
+09:39 < geertu> of the device, it should be described in the compatible string, or in
+09:39 < geertu> properties on the device node."
+09:40 < horms> what does "programming model" mean?
+09:40 < geertu> But we can't add renesas,pfc-r8a7795-es1 retroactively
+09:40 < geertu> = how you talk to the module
+09:41 < geertu> For CPG/MSSR the differences between ES versios are just additions and removals of registers and bits
+09:41 < geertu> for PFC I think it's slightly different, so "different programming model" may apply
+09:42 < geertu> warranting a compatible change
+09:43 < geertu> Any other comments about PFC?
+09:44 < shimoda> sorry i don't understand yet..
+09:44 < geertu> Shimoda: What should I explain better?
+09:44 < shimoda> bsp team have concern about the #define
+09:45 < shimoda> it will be conflict if we follow the datasheet
+09:46 < shimoda> or, any #defines is not useful after boot?
+09:48 < shimoda> this means the #define (e.g. IP9_7_4) is for just a programmer?
+09:49 < geertu> If we use pfc-r8a7796.c for H3 ES2, the definition of IP9_7_4 is correct, right?
+09:49 < shimoda> yes
+09:50 < geertu> If the only differeences between H3ES2 and M3-W are differences in pinmux_data[], we can use runtime patching
+09:51 < geertu> Of course we can start using a separate pfc-r8a7795-es2.c, and see if/what can be merged with pfc-r8a7796.c later
+09:53 < horms> Is it possible to do the reverse with a pfc-r8a7795-es1.c?
+09:53 < geertu> Yes we can
+09:54 < geertu> But I think pfc-r8a7795-es1.c still has to match against existing renesas,pfc-r8a7795
+09:54 < horms> That would seem slighly better in terms of future clean up imho
+09:54 < geertu> while new pfc-r8a7795.c would match against new renesas,pfc-r8a7795-es2
+09:54 < horms> well, unless its acceptable to make a hard incompatibility
+09:54 < geertu> unless we decide the "programming model" doesn't differ, and soc_device_match() is OK
+09:55 < geertu> for this purpose
+09:55 < horms> yes, i wonder what "programming model" means
+09:55 < geertu> "does it work with an unmodified driver"
+09:55 < horms> I think that in the long run renesas,pfc-r8a7795 should match what (first) goes into mass production
+09:56 < horms> which seems unlikely to be es1
+09:57 < geertu> Then we have no choice but to go for soc_device_match()
+09:58 < horms> I see your point that using soc_device_match() would make that goal easier
+09:58 < horms> goal = using renesas,pfc-r8a7795 with mass production chops
+09:58 < horms> well, my goal :^)
+09:59 < horms> what do you think is the best way forwards
+09:59 < horms> iirc you advocated using soc_device_match() in Berlin but a consensus was not reached in the group
+09:59 < geertu> If that is the goal, we have to go for soc_device_match()
+10:00 < horms> ok
+10:00 < geertu> which is fine for me (the "programming model" is IMHO a gray array for PFC)
+10:00 < horms> i think we need to continue this discussion with Magnus in the room as I'm sure he has an opinion on this
+10:01 < horms> tbh i'm kind of disturbed if Mark Rutland is setting policy we have to follow
+10:01 < horms> but if its grey then i have few complaints
+10:01 < geertu> This is not really a new policy
+10:01 < horms> ok, he was just stating the existing best practice?
+10:02 < shimoda> I have a question for ES2.0 support of PFC
+10:02 < shimoda> RFC patch of pfc-r8a7795.c said
+10:02 < shimoda>         } else {
+10:02 < shimoda>                 pr_info("%s: R-Car H3 >= ES2.0\n", __func__);
+10:02 < shimoda>                 // FIXME Fixup r8a7795_pinmux_info for ES2.0
+10:02 < shimoda>         }
+10:03 < shimoda> what will be appear at FIXME line?
+10:03 < shimoda> i cannot image it yet..
+10:03 < geertu> Code to modify struct sh_pfc_soc_info r8a7795_pinmux_info
+10:04 < geertu> e.g. to point to the r8a7796 tables instead, and patch them where needed
+10:06 < geertu> Does that explanation help?
+10:06 < shimoda> i see. the r8a7796 tables is in pfc-r8a7796.c? or copy & paste it into pfc-r8a7795.c?
+10:06 -!- horms2 [~horms@217.111.208.18] has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
+10:07 < geertu> shimoda: The r8a7796 tables are indeed in pfc-r8a7796.c
+10:07 < geertu> If we start with separate full tables, the code would make r8a7795_pinmux_info point either to the ES1.x or the ES2 tables
+10:09 < shimoda> i got it. for now some tables are "static". so should we modify the "static" for it?
+10:10 < geertu> If needed, we ahve to drop the static and/or const
+10:10 < shimoda> Thank you! I understood it!
+10:11 < geertu> Good.
+10:11 < geertu> Anyone who's also in MultiMedia who knows about "HDMI out" state?
+10:12 < morimoto> Maybe Ulich
+10:13 < horms> morimoto: maybe he is absent
+10:14 < morimoto> He has such additional task I think (prototype)
+10:14 < morimoto> After that Laurent will work for upstreaming
+10:15 < neg> I got some reports from Fukawa-san at Renesas who was testing VIN+DU on both VGA and HDMI out on H3 (i think) so something seems to work
+10:17 < geertu> So it's WIP
+10:18 < geertu> If it's working, I can add it to renesas-drivers
+10:18 < pinchartl> geertu: the plane was late, I'm in the train back home, and my luggage is sill in JFK
+10:18 < geertu> pinchartl: Oops
+10:19 < horms> at least you arrived on the scheduled day :)
+10:19 < geertu> pinchartl: The crew had to vote first? ;-)
+10:19 < pinchartl> please proceed without me today :-)
+10:20 < geertu> I think we're almost finished.
+10:21 < geertu> Unless someone has something to add (subtract, multiply, divide, ...)?
+10:22 < horms> nothing from my side
+10:22 < shimoda> nothing from me
+10:24 < geertu> Thanks for joining, and have a nice continued day