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
111
|
Core-chat-meeting-2018-10-04
09:35 < geertu> Welcome to Today's Core Group Chat!
09:35 < geertu> Agenda:
09:35 < geertu> 1. Status Updates
09:35 < geertu> 2. Discussion Topics
09:35 < geertu> Topic 1. Status updates
09:35 < geertu> A) What have we done since last time:
09:35 < geertu> Jacopo reviewed the RZ/N1 pinctrl driver.
09:35 < geertu> Marek worked on Linux PCIe 32bit DMA, ATF (memory config passing), and
09:35 < geertu> U-Boot (memory config passing, Gen3 USB PHY, TMIO SDMMC, SPL as minimon
09:35 < geertu> replacement).
09:35 < geertu> Morimoto-san discussed the PeriPeri process, reviewed BSP commit
09:35 < geertu> descriptions, and reports Magnu's Ebisu-4D has arrived.
09:35 < geertu> Shimoda-san says Renesas Vietnam started testing LTSI v4.14-rc2,
09:35 < geertu> discussed power management support in the IPMMU driver with Magnus, and
09:35 < geertu> submitted v2 of the usb2.0 host/peripheral property updates.
09:35 < geertu> Geert worked on virtualization (pass-through preparatory work, device
09:35 < geertu> reset, proof-of-concept for QEMU GPIO virtualization), sent
09:35 < geertu> clock/pinctrl pull requets, and upported/enabled INTC-EX on R-Car E3.
09:36 < geertu> B) What we plan to do till next time:
09:36 < geertu> Marek will continue ATF-U-Boot DT memory layout handoff and SPL
09:36 < geertu> experiments, and will revisit PCIe SError.
09:36 < geertu> Morimoto-san will create process images for ELCE.
09:36 < geertu> Shimoda-san says Renesas Vietnam will continue testing LTSI v4.14-rc2 until
09:36 < geertu> Oct 5th. He will discuss with Simon-san about R-Car E3 enablement.
09:36 < geertu> Geert will sent a third pinctrl pull-request for v4.20, Remove
09:36 < geertu> SoC-specific ARCH_* symbols to please arm-soc, and handle SYSC and PFC
09:36 < geertu> errata.
09:38 < geertu> Anything I missed?
09:38 < horms> geertu: I'd like to talk about those symbols and how to finalise getting our v4.20 patches accepted. But it can be outside of this meeting.
09:40 < geertu> OK, let me summarize
09:40 < geertu> Arnd asked to remove all SoC-specific ARCH_* symbols, as other vendors don't have them.
09:40 < geertu> However, this means the SoC-specific CLK_* and SH_PFC_* symbols will become user-visible.
09:41 < geertu> In addition, there are a few other places (mostly drivers/soc/renesas/) where these ARCH_* symbols are used, so they have to be "fixed".
09:42 < Marex> geertu: I wanna focus on U-Boot testing, but that's a detail
09:42 < geertu> We do want to avoid including too much unneeded stuff where it makes sense (e.g. RZ/A with internal SRAM only and XIP)
09:43 < geertu> horms: Any comments?
09:43 < horms> geertu: So I see we will need to make some adjustments. Will they be for both ARM and arm64? Once we have sorted out what they are, can we make sure everyone, including Chris Patterson, is aware so new patches follow the new way. I assume any changes will take effect in v4.21 at the earliest, in which case we can prod Arnd to take the existing pull request.
09:44 < geertu> horms: If we do it for arm64, I think it makes sense to do it for arm32, too.
09:44 < horms> It seems to me that Arnd has a policy that he wishes to enforce - for no other reason than it exists. Iguess we have to work with that.
09:44 < horms> Ok, consistency is good for me.
09:45 < horms> Is the plan to expose the CLK_* and SH_PFC_* symbols?
09:45 < horms> It doesn't seem terrible to me
09:45 < horms> Though it does seem slightly worse than the current situation
09:45 < geertu> We will need a new ARCH_RCAR_GEN3 symbol, as ARCH_RENESAS applies to arm64 and arm32, and Arnd was OK with that
09:46 < geertu> Correct, CLK_* and SH_PFC_* symbols will become user-visible (they already were for RZ/A1 and RZ/N1, as they may rely on the bootloader for pinctrl setup, to reduce kernel size)
09:46 < horms> Ok, I'm a little confused about the purpose of ARCH_RCAR_GEN3
09:47 < wsa_> ARCH_RENESAS64?
09:47 < horms> I assume it would cover RZ/G2 but not some other SoCs, say RZ/A2
09:47 < geertu> Correct.
09:47 < geertu> RZ/A2 is arm32, so not affected
09:47 < horms> Would it be user-visible?
09:48 < geertu> drivers/soc/renesas/Kconfig
09:48 < geertu> select RST_RCAR if ARCH_RCAR_GEN1 || ARCH_RCAR_GEN2 || \
09:48 < geertu> ARCH_R8A774A1 || ARCH_R8A774C0 || ARCH_R8A7795 || \
09:48 < geertu> ARCH_R8A7796 || ARCH_R8A77965 || ARCH_R8A77970 || \
09:48 < geertu> ARCH_R8A77980 || ARCH_R8A77990 || ARCH_R8A77995
09:48 < geertu> The last part would be replaced by ARCH_RCAR_GEN3
09:49 < geertu> Oh, we also have SYSC_*, forgot about those...
09:49 < geertu> But the sysc files are smaller, so we could always include them, based on SoC family.
09:50 < geertu> ARCH_RCAR_GEN3 would not be user-visible
09:50 < geertu> For now, once e.g. RZ/A3 becomes arm64, we need a new family selector.
09:50 < horms> Ok, so we would end up with the same amount or rst code compiled in
09:50 < horms> More sysc code, but it would be onl a little bit more
09:50 < horms> And pinctl and clk would be selected by the user
09:51 < geertu> Correct.
09:51 < horms> Ok, I understand
09:51 < geertu> pinctrl code for one SoC is O(tens of KiB)
09:51 -!- neg [~neg@unaffiliated/neg] has quit [Read error: Connection reset by peer]
09:51 < geertu> clock code for one SoC is O(some KiB)
09:51 < horms> This does seem slightly worse than the current situation. But if thats what Arnd wants I think we can live with it
09:51 < geertu> sysc code for one SoC is O(few hundred bytes)
09:52 -!- neg [~neg@unaffiliated/neg] has joined #periperi
09:52 < horms> I look forward to reciving a request from him to have per-soc Kconfig symbols to be more like other vendors :^)
09:52 < geertu> horms: That may come from Olof, or Kevin ;-)
09:52 < horms> Regarding v4.20, can we prod him to take the pull-request as is
09:52 < horms> geertu: haha
09:52 < geertu> horms: Probably yes.
09:52 < horms> Ok, will you prod him or shall I. If so, when?
09:53 < geertu> horms: Didn't he take your PR?
09:54 < horms> No, I don't think so.
09:54 < horms> I did check that yesterday
09:55 < horms> I don't see it in arm-soc/for-next
09:55 < geertu> Indeed. I will ask him to pull it.
09:55 < horms> Thanks
09:56 < horms> From my pov we have a way forwards to fix his greivance, and can likely implement it in v4.21, but we'd be most grateful if he could take the pr for v4.20 in its current form to enable our new hw in upstream in that release.
09:57 < horms> sorry to take so much of everyones time in the meeting
09:58 < geertu> Replied to Arnd.
09:58 -!- patersonc [c18ddb24@gateway/web/freenode/ip.193.141.219.36] has joined #periperi
09:58 < horms> dank u wel
09:58 < geertu> Inserting "Topic 2. Discussion Topics
09:58 < geertu> " above
09:58 < geertu> Any other discussion topics?
10:01 < wsa_> do we have a place to meet on Friday in Edinburgh?
10:01 < wsa_> I am not aware
10:02 < wsa_> but I may have missed it
10:02 < geertu> I am not aware, neither
10:02 < Marex> geertu: U-Boot testing ?
10:02 < pinchartl> wsa_: in that case I missed it too
10:02 < geertu> Anyone familiar with Edinburgh?
10:03 < Marex> geertu: U-Boot has a testsuite, so we should start running it continously
10:03 < wsa_> I can have a look
10:03 < geertu> Marex: yes, (automated) testing is great!
10:04 < Marex> geertu: do we do any automated testing for Linux ?
10:05 < geertu> wsa_: Thx!
10:05 < geertu> Marex: Not enough, I guess
10:06 < Marex> geertu: I think once I finish the current batch of tasks, I'd like to start looking in that direction
10:06 < geertu> Marex: That would be great!
10:08 < geertu> Time to pass the mic to pinchartl?
10:08 < geertu> Thanks for joining, and have a nice continued day!
|
