1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
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!
|
