Core-chat-meeting-2018-02-15 09:32 < geertu> Welcome to today's Core Group chat! 09:32 [Users #periperi] 09:32 [ geertu] [ kbingham ] [ marex-cloud] [ neg ] [ uli___] 09:32 [ horms ] [ kbingham[m]] [ morimoto ] [ pinchartl] [ wsa_ ] 09:32 [ jmondi] [ Marex ] [ mturquette ] [ shimoda ] 09:32 -!- Irssi: #periperi: Total of 14 nicks [0 ops, 0 halfops, 0 voices, 14 normal] 09:32 < geertu> FTR, Magnus is excused 09:32 < geertu> Agenda: 09:32 < geertu> 1. Status Updates 09:32 < geertu> 2. Discussion Topics 09:33 < geertu> Topic 1. Status updates 09:33 < geertu> A) What have we done since last time 09:33 < geertu> Jacopo submitted initial Salvator-x M3-N support. 09:33 < geertu> Marek submitted H2 Stout patches, and implemented RPC QSPI and HF 09:33 < geertu> drivers for U-Boot, incl. a method for easy updating of the bootloader 09:33 < geertu> using single fitImage payload. 09:33 < geertu> Shimoda-san submitted rcar-dmac fixes for max_chunk_size and 09:33 < geertu> rcar_dmac_chan_get_residue() issues. 09:33 < geertu> Simon posted and merged R8A77980 glue, misc cleanups, and tested 09:33 < geertu> CPUFreq/Z,Z2 Clock patches on big.LITTLE H3 and M3-W. 09:33 < geertu> Geert completed the GPIO pass-through prototype, wrote a generic 09:33 < geertu> vfio-platform reset driver, tried Fabrizio's R-Car Gen2 Watchdog Timer 09:33 < geertu> work, and extended it to all R-Car Gen2 SoCs and boards. 09:34 < geertu> EOT 09:34 < geertu> B) What we plan to do till next time 09:34 < geertu> Jacopo will address review comments and finalize M3-N upstreaming. 09:34 < geertu> Marek will submit Stout V2 after addressing feedback, and continue RPC 09:34 < geertu> work, also on D3/V3M. 09:34 < geertu> Shimoda-san will discuss a plan to improve the IPMMU driver with 09:34 < geertu> Magnus-san, and will submit M3-N PFC patches for USB. 09:34 < geertu> Simon will probably do more DT cleanups (soc node and sorting). 09:34 < geertu> Geert will run and improve Linux on M3-N Salvator-XS, and revisit 09:34 < geertu> in-kernel BD9571MWV DDR backup mode. 09:34 < geertu> EOT 09:36 < geertu> C) Problems we have currently 09:36 < geertu> Marek has issues with the slow U-Boot SD/MMC maintainer. 09:36 < geertu> Geert has issues with watchdog reset on early revisions of R-Car H2 and 09:36 < geertu> M2-W, and on V2H. 09:36 < geertu> EOT 09:36 < geertu> Anything missing? 09:37 < Marex> morimoto: thank you for the RPC stuff :-) 09:37 < geertu> About the watchdog issues: 09:37 < geertu> - R-Car H2 < ES2.0 and R-Car M2-W < ES3.0 (or < ES2.0?) need 09:37 < geertu> secondary cores offlined, 09:37 < geertu> - R-Car V2H ES1.1 needs CONFIG_SMP=n. 09:37 < geertu> Renesas UK doesn't care about these early revisions, but we all seem to have boards with such old SoCs. 09:38 < geertu> Hence I think we should blacklist them in the WDT driver using soc_device_match() 09:38 < wsa_> i am a bit confused that Simon took the dts patches already while the issues are still present. Is that intentional? 09:38 < horms> Good that they have newer hw than us! 09:38 < morimoto> Marex: my pleasure 09:38 < geertu> DT is hardware description 09:38 < horms> wsa_: we think the dt changes are clean but the driver side needs work 09:38 < horms> yes, it was intentional 09:38 < wsa_> ok 09:38 < horms> perhaps we will live to regret the decision 09:39 < horms> s/we/I/ 09:39 < Marex> morimoto: it really did help , cfr https://github.com/marex/u-boot-sh/commits/test/rpc , which is mostly done now (still need to fix one more cache issue there) 09:39 < wsa_> just wondering, because if we can't decide on a fix for 4.17, my Lager board could lock up when trying to reboot without PMIC drivers 09:40 < wsa_> but Geert's proposed fix looks fine to me 09:40 < horms> ok, so the current renesas-devel has the problem you describe? 09:40 < wsa_> haven't tried. from my experience, it should have 09:40 < wsa_> but i need to test obviously 09:40 < horms> ok, that is not good 09:40 < morimoto> Marex: looks nice ! Thank you for your help ! 09:40 < geertu> wsa_: And with a blacklist, it would not reboot without PMIC drivers? 09:40 < horms> please test :) 09:40 < wsa_> yes 09:41 < geertu> Given only the DT was accepted, there is no issue. 09:41 < wsa_> that is why I pushed the watchdog driver back then 09:41 < geertu> Watchdog driver has to go in last anyway 09:41 < geertu> v4.17: clocks 09:41 < geertu> v4.18: mach-shmobile reboot vector 09:41 < geertu> v4.19: watchdog driver 09:41 < geertu> v4.17: clocks + DT 09:42 < Marex> morimoto: sure, convenient method of updating u-boot/atf/etc is coming for 2018.05 or 07 (depends on how fast the maintainers react) 09:42 < wsa_> wow, this is a long term plan 09:42 < horms> ok, so its not until the driver goes in that problems can manifest? 09:42 < geertu> So we have plenty of time to perfect the blacklist ;-) 09:42 < geertu> horms: Correct. 09:42 < horms> ok, this is of course fine by me 09:44 < geertu> Topic 2. Discussion Topics 09:45 < geertu> From Shimoda-san: 09:45 < geertu> - H3 ES3.0 SiP will have 8GiB memory. 09:45 < geertu> - Do we need r8a7795-es2-salvator-x[s].dts? 09:45 < geertu> - E3 Ebisu board will have 2GiB memory, but first lot will have 1GiB. 09:45 < geertu> - I'd like to support 2GiB board only in upstream. 09:45 < geertu> EOT 09:45 < geertu> So both are related to memory size 09:45 < geertu> There's no need to describe all memory in DT, if U-Boot provides it. 09:45 < geertu> However, U-Boot now uses DT, so it needs a separate DTS? 09:45 < Marex> geertu: or we can extract how much RAM the board has from ATF somehow ? 09:45 < geertu> Or code to populate the memory node based on ES revision? 09:46 < Marex> geertu: then U-Boot can report it correctly and patch the Linux DT with the correct info 09:46 < geertu> shimoda: Will E3 be a SiP? Or a board with either 1 or 2 GiB populated? 09:46 < Marex> geertu: not ES revisions, that may not work if someone mixes and matches boards and CPUs 09:47 < morimoto> shimoda-san is talking with our boss now 09:47 < geertu> Marex: We already have that issue, as the H3 SiPs on Salvator-X and H3ULCB are different (different memory size + ???) 09:47 < Marex> geertu: isnt there some SMC call which can give you the DRAM configuration ? 09:47 < geertu> Marex: no idea 09:47 < Marex> geertu: that might be the thing to explore 09:47 < Marex> geertu: that way we can be always correct IFF the ATF is correct 09:48 < geertu> Marex: Yes, you want a shared U-Boot binary, while the ATF is still per-SoC 09:48 < Marex> geertu: I want one u-boot to rule them all ! 09:48 < Marex> geertu: one u-boot binary, with different DT attached to it on per-board basis, that'd be AWESOME 09:49 < Marex> geertu: but if we can avoid having per-memory-configuration DT for u-boot, that'd be AWESOME too 09:50 < Marex> geertu: ... before you mention applying DTOs to U-Boot DT, yes, I tried it, no, I don't want to go down that path here ;-) 09:51 < geertu> At one point, I considered SiP DT bindings and .dtsi 09:51 < geertu> "[PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP" 09:51 < geertu> https://www.spinics.net/lists/devicetree/msg173820.html 09:51 < shimoda> geertu: sorry for delayed. E3 is not SiP. SDRAM on board 09:51 < geertu> shimoda: Thanks for checking. 09:52 < Marex> geertu: or apply DTOs to Linux DT on U-Boot level now ? :) 09:52 < geertu> shimoda: Will there be other differences in H3 ES3.0 to warrant a new .dts(i) file? 09:53 < shimoda> geertu: i don't know, i will ask some guy 09:55 < geertu> shimoda: OK, we will see 09:57 < shimoda> geertu: hw team is preparing such document. so, after i got it, i will inform you. 09:57 < Marex> morimoto: one thing which would be real cool in the ATF on Salvator-X would be if there was one of those switches on the board to unlock the RPC HF 09:57 -!- horms [~horms@83.137.1.222] has quit [Ping timeout: 260 seconds] 09:58 < Marex> morimoto: this way I won't have to hack the ATF to unlock the access to RPC on H3/M3 09:58 < Marex> morimoto: it'd also make it convenient for users of the board, just flip a switch, update u-boot from u-boot, reboot, flip the switch back to "locked" 09:58 < geertu> Marex: IIRC, there's an MD switch to boot from external FLASH. Does that also go through the RPC? 09:58 < Marex> morimoto: I think I'll prepare some patches for that, maybe renesas ATF tean can integrate them if they like it 09:59 < geertu> shimoda: Thank you 09:59 < geertu> Any other topics to discuss? 09:59 < Marex> geertu: everything goes through RPC afaik 10:01 < geertu> OK, let's conclude 10:01 < geertu> Thanks for joining, and have a nice continued day!