1 files changed, 110 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180301-core-chatlog b/wiki/Chat_log/20180301-core-chatlog
new file mode 100644
index 0000000..b351f51
--- /dev/null
+++ b/wiki/Chat_log/20180301-core-chatlog
@@ -0,0 +1,110 @@
+Core-chat-meeting-2018-03-01
+
+09:49 < geertu> Welcome to today's Core Group Chat!
+09:50 < geertu> First I'd like to welcome Vaishali
+09:50 < geertu> Agenda:
+09:50 < geertu> 1. Status Updates
+09:50 < geertu> 2. Discussion Topics
+09:50 < geertu> Topic 1. Status updates
+09:51 < geertu> A) What have we done since last time:
+09:51 < geertu> Jacopo continued upstreaming basic R-Car M3-N support.
+09:51 < geertu> Niklas fixed the CLKOUT duplicate pin on R-Car H3 ES2.0.
+09:51 < geertu> Shimoda-san discovered a new IPMMU issue on R-Car H3 ES3.0, and submmitted
+09:51 < geertu> USB-related PFC patches for R-Car M3-N.
+09:51 < geertu> Simon posted R-Car M3-N initial infrastructure patches.
+09:51 < geertu> Ulrich up-ported PFC work for R-Car H3/M3-W from the BSP (TMU/HDMI/fixes).
+09:51 < geertu> Geert did some R-Car M3-N work (initial Salvator-XS DTS, s2ram), and more
+09:51 < geertu> watchdogi investigation (blacklisted early R-Car Gen2 SoCs, Gen2 vs. Gen3 
+09:51 < geertu> comparison).
+09:51 < geertu> Marek is excused, and enjoying(?) Embedded World
+09:52 < geertu> B) What we plan to do till next time:
+09:52 < geertu> Shimoda-san will submit PWM PFC and USB DTS patches for R-Car M3-N, and
+09:52 < geertu> discuss with Magnus a plan to improve the IPMMU driver.
+09:52 < geertu> Simon will probably do more DTS cleanup work (soc node and sorting).
+09:52 < geertu> Geert will post V2 of in-kernel BD9571MWV DDR backup mode, and revisit vfio
+09:52 < geertu> and qemu patches.
+09:52 < geertu> C) Problems we have currently:
+09:52 < geertu> Geert wonders if s2ram (PSCI suspend) works on ULCB, and Shimoda-san
+09:52 < geertu> confirmed it.
+09:53 < geertu> Anything I missed?
+09:55 < geertu> Topic 2. Discussion Topics
+09:55 < geertu> 1. SW feedback to HW team for R-Car Gen4.
+09:55 < geertu> Personally, I have the following:
+09:55 < geertu>   - Virtualization:
+09:55 < geertu>       - All device instances should be resettable independently
+09:55 < geertu>         (e.g. PWM and DU share resets).
+09:55 < geertu>       - All device instances should be mappable independently
+09:55 < geertu>         (e.g. GPIO5/6/7 share (4 KiB) pages)
+09:56 < geertu> Any other feedback?
+09:56 < geertu> (IOMMU? ;-)
+09:56 < neg> geertu: I have MM related feedback, do we split this per group or handle the topic for all groups now?
+09:57 < geertu> neg: I think it makes sense to do it per-group, that's why I didn't mention your feedback
+09:58 < neg> geertu: :-)
+10:01 < geertu> OK, core is further perfect ;-)
+10:01 < geertu> 2. RZ/N1D upstreaming.
+10:01 < jmondi> no feedbacks from me (apart general reamarks on PFC, but I don't think they will listen :)
+10:01 < geertu> So Renesas submitted two large patches to add support for RZ/N1D on the RZ/N1D-DB Board
+10:02 < geertu> From a quick glance, there are several arres for improvement:
+10:02 < geertu> - Too large patches
+10:02 < geertu> - Board code
+10:02 < geertu> - Macros in DTS
+10:03 < geertu> So far I didn't reply in public, as I feel this is more appropriate for the official mach-shmobile maintainers
+10:03 < jmondi> can I ask some questions on those patches, for informative purpose?
+10:03 < geertu> jmondi: Sure
+10:03 < jmondi> why they had to use board code? I see r7s72100 does the same...
+10:04 < jmondi> I guess it's beacuse RZ is njot integrated in cpg-mssr, right?
+10:04 < jmondi> and even in that case, why do not use something like drivers/clk/rz/ and drivers/soc/rz/ ...
+10:06 < geertu> Probably we can get rid of arch/arm/mach-shmobile/setup-r7s72100.c
+10:06 < geertu> It predates true DT support
+10:06 < geertu> I guess they just took the quick and dirty approach
+10:07 < geertu> horms: dammsan: Any comments from the mach-shmobile maintainers?
+10:08 < horms> Well, my assumption is that the upstream policy is no more board files
+10:08 < horms> So from my point of view the question is: how can support be added for RZ/N1D without a board file
+10:09 < horms> There is also a similar, but arguably smaller, issue of a defconfig for the platform
+10:09 < geertu> The board file contains sysctrl initialization (should be syscon node in DT instead), and a restart handler (should be a drivers/power/reset/ driver)
+10:10  * jmondi thorws himself into the fire: I would like to remove board code from RZ/A... do you think there is any value there and it can be reused for RZ/N?
+10:10 < dammsan> i agree =)
+10:10 < geertu> There's not much R-{Car,Mobile} DNA shared
+10:11 < geertu> jmondi: I encourage that task. But the board code for RZ/N1D is completely different from the one for RZ/A1.
+10:12 < jmondi> I admit I haven't looked into RZ/N1D HW at all yet
+10:14 < geertu> Looks like the DTB isn't even built...
+10:14 < horms> Ok, so I think we should push back
+10:14 < horms> I can do so. But I'm happy for someone else to do so.
+10:14 < geertu> horms: Will you reply?
+10:14 < geertu> IC
+10:14 < horms> But we can't try to push a board file unless we have no other practical option
+10:14 < geertu> I can reply with some technical feedback
+10:14 < horms> Sure, will do
+10:15 < dammsan> thanks guys
+10:15 < horms> Thanks for bringing this up, I was also not sure how to proceed
+10:15 < shimoda> about RZ/N, we don't need any document for now?
+10:16 < geertu> shimoda: You are trying to get documentation, IIRC? (some RZ/N1D docs are public)
+10:16 -!- wsa_ [~wsa@p54B339A5.dip0.t-ipconnect.de] has quit [Quit: ...]
+10:16 < shimoda> geertu: yes, I'm asking now.
+10:17 < geertu> I downloaded 4 PDF datasheets
+10:17 < geertu> User’s Manual: System Introduction, Multiplexing,
+10:17 < geertu> Electrical and Mechanical Information
+10:17 < geertu> User’s Manual: Peripherals
+10:17 < geertu> User’s Manual: System Control and Peripheral
+10:18 < geertu> User’s Manual: R-IN Engine and Ethernet
+10:18 < geertu> Peripherals
+10:18 < geertu> No idea if this is complete
+10:18 < geertu> But it's a start
+10:20 < geertu> shimoda: Thanks!
+10:20 < geertu> Any other discussion topics?
+10:21 < neg> Not from me
+10:21 < jmondi> geertu: no but yesterday you asked me if I have an ecovec
+10:21 < shimoda> i have a minor topic
+10:21 < jmondi> yes, Hans sent me one, but without camera modules :(
+10:21 < jmondi> and I have an ULCB if you need testing for s2ram
+10:21 < jmondi> shimoda: sorry shimoda-san, go on please
+10:22 < geertu> jmondi: OK, so Hans no longer wants to be ecovec maintainer ;-)
+10:22 < shimoda> about CMA_SIZE, it's default size is 16MiB. In general, if we want to change the size, we should use bootargs cma= or change the kernel config?
+10:22 < shimoda> in renesas_defconfig, it has =128
+10:22 < shimoda> but, defconfig doesn't have the config, so it's default 16MiB.
+10:24 < geertu> shimoda: You mean arm64_defconfig doesn't have it?
+10:24 < kbingham> shimoda: bootargs will take precedence, so you can set a value you want there easily
+10:26 < shimoda> geertu: yes. and thank you for your comment. i got it!
+10:26 < shimoda> kbingham: thanks for your comment!
+10:27 < geertu> I think we're finished?
+10:28 < geertu> Thanks for joining, and have a nice continued day!