wiki: Add Core chatlog for 2021-09-02

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

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!