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!