From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20180301-core-chatlog | 110 ++++++++++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) create mode 100644 wiki/Chat_log/20180301-core-chatlog (limited to 'wiki/Chat_log/20180301-core-chatlog') 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! -- cgit v1.2.3