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
|
09:31 < geertu> Welcome to today's Core Group Chat Meeting!
09:31 < geertu> Agenda:
09:31 < geertu> 1. Status Updates
09:31 < geertu> 2. Discussion Topics
09:31 < geertu> Topic 1. Status updates
09:31 < geertu> A) What have we done since last time:
09:31 < geertu> Marek debugged R-Car PCIe power state change failures and created a
09:31 < geertu> better fix.
09:31 < geertu> Morimoto-san remade the Renesas ROM writer, added Yocto Maker v5.9.0
09:31 < geertu> support, and did Renesas work.
09:31 < geertu> Shimoda-san submitted R-Car S4 IPMMU patches, realized that the Spider
09:31 < geertu> board has a different UFS chip, and investigated R-Car S4 PFC/GPIO
09:31 < geertu> control domain impact.
09:31 < geertu> Geert posted R-Car S4-8 pinctrl and GPIO patches, reviewed lots of
09:31 < geertu> patches, updated bsp51x tasks in periject, and participated in FOSDEM.
09:31 < geertu> B) What we plan to do till next time:
09:31 < geertu> Marek plans to try the new PCIe power state change fix on R-Car Gen3
09:31 < geertu> without the old fix in ATF.
09:31 < geertu> Morimoto-san plans to do Renesas work.
09:31 < geertu> Shimoda-san plans to follow up R-Car S4 IPMMU and PWM, review R-Car S4
09:31 < geertu> PFC/GPIO patches, and prepare initial support for R-Car V4H.
09:31 < geertu> Geert plans to send pull requests for v5.18, review more patches, and do
09:31 < geertu> BSP mining.
09:32 < geertu> C) Problems we have currently:
09:32 < geertu> Shimoda-san is worried about board shipping.
09:32 < geertu> Geert cannot access R-Car S4 PFC/GPIO banks 4 and up.
09:32 < geertu> ---EOT---
09:32 < geertu> Anything I missed?
09:33 < marex> I did re-push a small openocd sctlr handler, but that's not very important
09:33 < wsa> geertu: thanks for the periject updates!
09:33 < geertu> shimoday: I'm a bit confused about "pwm without a use case". Isn't it useful to have PWM support in general?
09:33 < marex> it's for when the soc starts in some odd mode and sctlr is misconfigured, that allows you to fix it up
09:35 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Remote host closed the connection]
09:35 < shimoday> geertu: I thought one of use cases about PWM is backlight
09:35 < shimoday> but, S4 doesn't have any display
09:35 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has joined #periperi
09:35 < geertu> Also, if PFC/GPIO banks 4 and up are blocked for Linux, we cannot use any of the functions on those pins (EtherAVB drive strength, CAN, MSPI)
09:36 < geertu> shimoday: display backlight is indeed one of the use cases
09:36 < shimoday> geertu: you're correct. About EtherAVB on control domain, I'm thinking it's difficult to use it on Cortex-A55
09:36 < shimoday> because the EtherAVB cannot use the DBSC directly IIUC
09:37 < shimoday> s/the DBSC/SDRAM of Cortex-A55/
09:37 < shimoday> in other words, Linux on S4 should not use any control domain's hardware
09:38 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Remote host closed the connection]
09:38 < shimoday> this is in my opinion though...
09:38 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has joined #periperi
09:38 < geertu> OK, until someone wants to run Linux on the CR52
09:39 < geertu> So we have to two things:
09:40 < geertu> 1. GPIO: either (a) drop gpio and 4 up nodes from DT, or (b) keep them disabled
09:40 < geertu> s/and 4 up/4 and up/
09:41 < geertu> 2. PFC: (a) drop banks 4 and up from the driver, or (b) keep them in the driver (they're not accessed unless DT has pin configuration referring to them)
09:42 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Remote host closed the connection]
09:42 < geertu> Do you have a preference?
09:42 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has joined #periperi
09:42 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Remote host closed the connection]
09:43 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has joined #periperi
09:43 < shimoday> geertu: (a) is easy implimantation than (B)?
09:44 < geertu> shimoday: yes it is. but the DTS and code have already been written ;-)
09:44 < shimoday> geertu: i see :)
09:45 < wsa> but why would we keep written code if we can't use it?
09:46 < geertu> The control domain protection can be disabled, right?
09:47 < wsa> I just read "Linux on S4 should not use any control domain's hardware"
09:47 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Ping timeout: 256 seconds]
09:47 < geertu> wsa: Shimoda-san reported "So, BSP team used TAUD hardware of the control domain with releasing control domain protection."
09:48 < wsa> didn't he want the BSP team to stop using TAUD?
09:49 < geertu> wsa: yes he did
09:50 < shimoday> is it possible to choose (a) first, and change (b) if someone wants?
09:50 < geertu> Sure, we can always re-add the DTS/code later
09:51 < shimoday> in perfect world, I believe application domain should not use any control domain hardware
09:51 < shimoday> but, someone is possible to request us such a nich thing, I guess...
09:52 < geertu> shimoday: Do you know how to release the control domain protection?
09:53 < shimoday> geertu: I guess we have to use other IPL of ICUMX
09:53 < shimoday> but, i'm not sure such IPL exists though...
09:54 < shimoday> since we can re-add the DTS/code later, i prefer (a) now
09:55 < geertu> OK
09:55 < shimoday> geertu: thanks!
09:58 < geertu> shimoday: I have a question about IPMMU usage on R-Car S4.
09:58 < geertu> "mw eed01500 0xc0000000; mw eed41500 0xc0000000" changes IMSCTLR?
09:59 < shimoday> geertu: yes, these change IMSCTLR
10:00 < geertu> shimoday: So we cannot really use the IPMMU until we have updated the boot loader?
10:02 < shimoday> geertu: we can use the IPMMU now because current IPL/U-Boot seem not to enter non-secure mode. So, we can write the registers on U-Boot.
10:03 < geertu> shimoday: but we always have to do that. or it will fail (crash?)
10:03 < shimoday> geertu: yes we always have to do that. otherwise, data mismatch happens
10:04 < geertu> OK
10:04 < geertu> Anything else to discuss?
10:04 < geertu> Next meeting?
10:05 < geertu> March 10th?
10:05 < wsa> I'd suggest a regular meeting on march, 10th and a farewell-for-now-meeting on march 31st
10:05 < geertu> Fine for me
10:05 < pinchartl> should we combine the two ? :-)
10:06 < shimoday> 10th and 31st are good to me
10:06 < uli> +1
10:06 < moriperi> +1
10:06 < wsa> pinchartl: i thought about it but think our good collaboration deserves a celebrational meeting
10:07 < pinchartl> how does one celebrate on IRC ?
10:07 < kbingham> wine and beer at 8am ? ;-)
10:07 < wsa> pinchartl: you have a few weeks left to find your preferred ASCII-art site ;)
10:08 < geertu> pinchartl: You haven't learnt anything during the last 2 years? ;-)
10:08 < wsa> "wine and beer" - now kbingham woke up :D
10:08 < kbingham> I have kids, I've been woken up since early am ;-)
10:08 < moriperi> geertu: :)
10:08 < moriperi> wsa: :)
10:09 < wsa> kbingham: yes, I should have said "now we got your attention"
10:09 < pinchartl> if we want to celebrate, we could as well go all the way and make it a video meeting
10:10 < wsa> pinchartl: wow, elegant shift of topics to start the MM meeting
10:11 < pinchartl> can we ?
10:11 < marex> heh
10:11 < wsa> we do a video meeting with our clients all running on Renesas HW \o/
10:11 < pinchartl> I'll have a hard stop today due to back-to-back meetings
10:11 < geertu> We can sit at a very large table, with a board with GSML cameras in the center?
10:11 < geertu> Doh, GMSL
10:12 < geertu> Thanks for joining, and have a nice continued day!
|
