diff options
| -rw-r--r-- | wiki/Chat_log/20210902-core-chatlog | 127 |
1 files changed, 127 insertions, 0 deletions
diff --git a/wiki/Chat_log/20210902-core-chatlog b/wiki/Chat_log/20210902-core-chatlog new file mode 100644 index 0000000..a71060c --- /dev/null +++ b/wiki/Chat_log/20210902-core-chatlog @@ -0,0 +1,127 @@ +09:38 < geertu> Welcome to today's Core Group Chat Meeting! +09:38 < geertu> Agenda: +09:38 < geertu> 1. Status Updates +09:38 < geertu> 2. Discussion Topics +09:38 < geertu> Topic 1. Status updates +09:38 < geertu> A) What have we done since last time: +09:38 < geertu> Marek sent and debated the growing LMB patchset on tghe U-Boot mailing +09:38 < geertu> list, sent V7 of the Gen2 PCIe L1 mode fix for Linux, and submitted +09:38 < geertu> another batch of Gen3 ATF patches. +09:38 < geertu> Morimoto-san added a new board to the Renesas Remote Access System, +09:38 < geertu> created an Auto ROM Writer for Linux, and did Renesas Work. +09:38 < geertu> Shimoda-san submitted initial IPMMU support for R-Car V3U. +09:38 < geertu> Geert sent pull requests for v5.15, enjoyed Summer holidays, submitted +09:38 < geertu> generic support for kdump DT properties v5, posted the remainder of the +09:38 < geertu> R-Car Gen3e support patches, and reviewed more RZ/G2L patches. +09:39 < geertu> B) What we plan to do till next time: +09:39 < geertu> Kieran plans to test INTC-EX on Falcon. +09:39 < geertu> Marek plans to send the version version of the U-Boot LMB patchset, and +09:39 < geertu> to unblock ATF patches by adding his own CoR (Code-Owner-Review). +09:39 < geertu> Morimoto-san plans to continue working on the new boards and the ROM +09:39 < geertu> writer. +09:39 < geertu> Shimoda-san plans to pepare initial R-Car S4 support. +09:39 < geertu> Geert plans to look into interrupt support for gpio-aggregator, review +09:39 < geertu> more RZ/G2L patches, and post more pinctrl validation code. +09:40 < geertu> C) Problems we have currently: +09:40 < geertu> Morimoto-san is suffering from complex Renesas Work Problems. +09:40 < geertu> Geert is suffering from his back. +09:40 < geertu> ---EOT--- +09:40 < geertu> Anything I missed? +09:40 < marex> geertu: you dont submit patches to atf, you push them +09:40 < geertu> marex: I'm happy to see the ATF submission path was cleared! +09:40 < geertu> s/submission/push/ +09:42 < geertu> Topic 2. Discussion Topics +09:42 < geertu> A) R-Car V3H2 +09:42 < geertu> I think we have three options: 1. Use the same compatible values as R-Car V3H ES1.x +09:43 < geertu> 2. Use new compatible values ("r8a77980a"-based). +09:43 < geertu> 3. Use the same compatible values as R-Car V3H ES1.x +09:43 < geertu> but add "renesas,r8a77980a" to the top compatible value +09:43 < geertu> pinchartl said: Do we have an idea of how many drivers would need to handle differences +09:43 < geertu> between V3H and V3H_2 ? +09:44 < geertu> Anyone who wants to comment? +09:45 < pinchartl> I don't have any answer to that, otherwise I wouldn't have asked :-) +09:45 < damm> like pinchartl says it must depend on expected device coverage +09:46 < wsa> let me check, i think i saw a patch in the BSP saying HS400 is broken on SDHI for V3H ES1 but not ES2 +09:46 < geertu> Ok, so -ENEEDMOREINPUT +09:47 < damm> geertu: i like how you described the different approaches so clearly in your email +09:48 < geertu> damm: Thanks. Sometimes it's good to clearly state what we tried before +09:49 < wsa> c34be4cd8782 ("mmc: renesas_sdhi: Allow HS400 for R-Car V3H ES2.x") +09:49 < geertu> wsa: While the BSP tells you about some difference, it probably doesn't cover everything yet. +09:50 < wsa> sure +09:52 < damm> geertu: is it a valid approach to begin with one way during early upstreaming and switch after some time when we know more? +09:52 < geertu> damm: It is, if we clearly mark the initial work as preliminary, to avoid "stable" expectations +09:53 < geertu> So we can go with option 3., and fall back to .2 if it turns out to become horrible. +09:53 < wsa> sounds sane to me +09:53 < damm> seems like a quite clever approach to me +09:53 < geertu> "Full hardware and software compatibility with the currently mass-produced R-Car V3H SoC;" +09:53 < wsa> I think 3) worked well enough for Gen3e? +09:54 < geertu> wsa: For Gen3e, the actual SoCs dies are the same +09:54 < geertu> like Intel i7/i5/i3 +09:54 < wsa> i think it is still reasonable to assume that it is not an entirely new SoC but an "just" updated one +09:55 < wsa> that's all we have today +09:55 < geertu> wsa: V3H2 is V3H ES2.0, so a different die. +09:55 < geertu> wsa: yes, it cleams to be V3H with some additions (and changes?) +09:55 < wsa> bugfixes +09:55 < wsa> :/ +09:55 < geertu> additions are usually fine, if they involve just adding device nodes +09:55 < damm> maybe they've routed the thermal interrupts to the DU or something +09:56 < geertu> removals can be fine too, if they involve just deleting device nodes +09:56 < geertu> The tricky parts are the changes +09:56 < geertu> Note that even for adding/removing modules, we need changes to the CPG/MSSR driver +09:56 < wsa> damm: to visualize the climate change? makes sense... +09:57 < damm> but will V3U ES1 ever be mass produced? +09:57 < geertu> So using "renesas,r8a77980a-cpg-mssr" from the start may make sense +09:57 < damm> i mean V3H. my gut feeling is that we should always track the latest and focusing on old stuff might not be the smartest move +09:58 < geertu> damm: "... compatibility with the currently mass-produced R-Car V3H SoC" +09:58 < damm> oh right sorry +09:58 < geertu> damm: but it is a good question. +09:58 < damm> so maintaining both versions makes sense then +09:58 < geertu> If you Google for V3H2, you find the Renesas Scout PDF, which lists "R-Car M3" with part number R8A77961 +09:59 < geertu> Nothing about M3-W or M3-W+, so it looks like nowadays only M3-W+ is mass-produced. +10:01 < damm> that would make sense +10:01 < geertu> https://www.renesas.com/us/en/document/bro/product-scout-automotive?language=en +10:01 < geertu> It lists H3, H3N, M3 (=W+), M3N, E3, D3, V3M, V3H, V3U +10:02 < geertu> and V3H is R8A77980A, so V3H2 +10:02 < damm> another approach could be to use the same DT compatible strings for all ES versions and simply disable unsupported on-chip devices for old ES versions during runtime +10:02 < damm> spending time to develop code on an old ES version seems like focusing on the wrong thing anyway +10:03 < pinchartl> damm: wouldn't that require drivers to use soc matching ? that's not nice +10:03 < geertu> damm: Makes sense, except that we uusually don't have ubiquitous access to the latest ES versions +10:04 < geertu> pinchartl: Not necessarily individual drivers. Think of early drivers/soc/renesas/ code that removes devices nodes from FDT depending on detected ES version +10:04 < damm> i expected some central shared SoC-specific ES handling code to force disabling of problematic devices by changing the DT structure or some part of the device model (equivalent to status = disabled) +10:04 < damm> not to scatter the stuff across the tree +10:05 < geertu> damm: So that would render almost all my boards unusable? +10:05 < pinchartl> isn't that working around the fact that DT should not provide an incorrect description in the first place ? +10:05 < damm> some devices on some boards would be disabled i guess. i have no idea how many devices that would be affected though +10:05 < geertu> pinchartl: Exactly +10:06 < pinchartl> so it's a DT problem, we don't have to do anything, next :-) +10:06 < damm> yeah i guess so. you are right +10:06 < geertu> Anything else to discuss? +10:07 < damm> OpenOCD on 64-bit ARM +10:07 < damm> in particular breakpoints +10:07 < damm> anyone with experience using those? +10:07 < damm> i've used breakpoints and watchpoints on other ARM cores with success +10:07 < damm> however i can't see to get breakpoints going on 64-bit ARM with OpenOCD +10:08 < damm> obviously i could be doing something wrong with the different levels of execution +10:09 < damm> so if anyone has experience in this field please let me know +10:11 < geertu> damm: Should I add that to your C) Problems I have currently +10:11 < geertu> ? +10:11 < damm> that might be a good idea. thanks. +10:12 < geertu> Shall we wrap up? +10:12 < geertu> Next meeting date? +10:13 < wsa> Oct, 7th? +10:13 < shimoday> 30th Sep or 7th Oct? +10:13 < geertu> 30th sep is ELC +10:14 < geertu> (virtual for all you you, I guess?) +10:14 < geertu> s/you you/of/you/ +10:14 < pinchartl> not during ELC please :-) +10:14 < wsa> I have registered for LPC but not ELC +10:14 < geertu> s/you you/of you/ +10:14 < geertu> 7th Oct is fine for me +10:14 < geertu> pinchartl: virtual or real? +10:14 < shimoday> oops, I forgot about ELC :) so, 7th Oct is better +10:15 < pinchartl> virtual +10:15 < pinchartl> but presenting +10:16 < moriperi> 7th Oct is OK for me +10:16 < pinchartl> (ok, not on the same day :-)) +10:17 < geertu> So let's go for 7th Oct +10:17 < geertu> Thanks for joining, and have a nice continued day! |