wiki: Add Core chatlog for 2020-11-26

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

1 files changed, 111 insertions, 0 deletions

diff --git a/wiki/Chat_log/20201126-core-chatlog b/wiki/Chat_log/20201126-core-chatlog
new file mode 100644
index 0000000..ca239c4
--- /dev/null
+++ b/wiki/Chat_log/20201126-core-chatlog
@@ -0,0 +1,111 @@
+09:43 <@geertu> Welcome to today's Core Group Chat Meeting!
+09:43 <@geertu> Agenda:
+09:43 <@geertu> 1. Status Updates
+09:43 <@geertu> 2. Discussion Topics
+09:43 <@geertu> Topic 1. Status updates
+09:44 <@geertu> A) What have we done since last time:
+09:44 <@geertu> Marek worked on U-Boot (late clock drivers removal) and TFA (BL31
+09:44 <@geertu> logging fix).
+09:44 <@geertu> Morimoto-san continued V3U-Falcon shipping paper work.
+09:44 <@geertu> Niklas posted VIN "g8" pin control patches.
+09:44 <@geertu> Shimoda-san submitted the rcar-usb2-clock-sel json-schema conversion.
+09:44 <@geertu> Ulrich finished porting V3U pin control from the BSP.
+09:44 <@geertu> Geert tested GPIO on R-Car V3U, fixed R and OSC clocks on R-Car V3U,
+09:44 <@geertu> removed static I/O mappings from mach-shmobile, sent first batch of pull
+09:44 <@geertu> requests for v5.11, and studied the early ARM compressed boot flow,
+09:44 <@geertu> fixing large kernels on Koelsch.
+09:44 <@geertu> B) What we plan to do till next time:
+09:44 <@geertu> Marek is considering to revisit the U-Boot PSCI implementation.
+09:44 <@geertu> Morimoto-san plans to continue doing V3U-Falcon paperwork, and do
+09:44 <@geertu> Renesas work.
+09:44 <@geertu> Shimoda-san plans to collect more information about R-Car Gen3e,
+09:44 <@geertu> add BD9574 support for Ebisu-4D board (depending on hardware
+09:44 <@geertu> availability), and attend OSSJ + ALS2020.
+09:44 <@geertu> Ulrich plans to post V3U pin control support.
+09:44 <@geertu> Geert plans to send the second batch of pull requests for v5.11,
+09:44 <@geertu> complete R-Car V3U gpio-pinctrl integration, and develop v10 of
+09:44 <@geertu> obtaining the start of physical memory from DTB.
+09:44 <@geertu> C) Problems we have currently:
+09:44 <@geertu> None.
+09:45 <@geertu> ---EOT---
+09:45 <@geertu> Anything I missed?
+09:45 <@geertu> Looks like we're on track regarding R-Car v3U support?
+09:46 < wsa> uli__: when do you plan to post the PFC driver?
+09:46 < uli__> i'll try to do it today. tomorrow at the latest.
+09:48 <@geertu> shimoday: Given you already did preparatory work for V3U SYS-DMAC in July 2019, do you plan to upstream support for it?
+09:48 <@geertu> uli__: thx!
+09:49 < wsa> uli__: cool!
+09:50 < shimoday> @geertu: i don't have any plan for now.
+09:51 <@geertu> shimoday: OK. So we'll have to tackle it once we have some I/O devices working that can make use of it.
+09:51 <@geertu> Topic 2. Discussion Topics
+09:51 <@geertu> A) KVM/Qemu situation.
+09:51 < shimoday> @geertu: yes. thanks!
+09:51 <@geertu> Morimoto-san reported that Munakata-san wants to know the KVM/Qemu situation.
+09:52 < moriperi> Yes. it seems KVM/Qemu is/will important
+09:52 < moriperi> for TOYOTA and/or Android
+09:52 < moriperi> So he want to know plan and/or your opinion
+09:52 <@geertu> The initial work we did, and which is documented on the elinux wiki, was basically an investigation and prototyping phase.
+09:52 <@geertu> No confidential information was "opened".
+09:53 < moriperi> OK
+09:53 <@geertu> AFAIK, we have no further plans.
+09:53 <@geertu> Before we reply to Morimoto-san's email, I think it would be good to have an ida of the planned use cases and expectations from Renesas.
+09:53 <@geertu> s/ida/idea/
+09:54 <@geertu> Looks like the request is mostly tiggered by what Google wants to do on Android?
+09:54 < moriperi> I'm not good at KVM, but he said that virt I/O, virt Video (?), virt Sound (?) virt USB (?), etc, etc will be needed.
+09:55 < moriperi> for Android, he said.
+09:55 < moriperi> and TOYOTA is having interresting about it.
+09:55 <@geertu> https://lwn.net/Articles/836693/ KVM for Android
+09:56 < moriperi> Renesas side have not concrete idea/plann so far.
+09:56 < moriperi> That is the reason why he want to know your side opinition.
+09:56 < shimoday> moriperi: virt USB means usb gadget? or host? perhaps gadget for android?
+09:56 <@geertu> I may be mistaken, but I think all of this virt I/O, virt Video, virt Sound, and virt USB is platform-independent?
+09:57 < wsa> yes, but it needs to be done
+09:57 <@geertu> wsa: "it"?
+09:57 < wsa> some people sent virt-io for I2C patches just the last weeks
+09:58 < wsa> probably because of exactly the effort morimoto-san mentions
+09:58 <@geertu> wsa: Yeah, if you see weird things appearing these days, it's usually triggered by some Google Android push
+09:59 < damm> i wonder if the next logical step after GPIO virtualization would be UART?
+10:00 < damm> with whatever in-kernel UART consumer interface it might be possible to arrange something not too ugly looking?
+10:00 <@geertu> damm: Doesn't that exist already? Serial console, disk, and net were the first I/O devices supported
+10:00 < wsa> so, I guess something to tell Munakata-san is that we generally favor KVM over Xen?
+10:00 < damm> sure, but we are talking both guest-virtio side and host backing driver too?
+10:00 < wsa> and he would probably like to see KVM running on R-Car?
+10:00 <@geertu> Now, this "KVM for Android" seems to be the inverse of what people usually do: they want to protect the guest against the host, not vice vera
+10:01 < damm> i'm wondering if host backing side can be connected to physical uart
+10:01 <@geertu> damm: (1st hit) https://stackoverflow.com/questions/39373236/redirect-multiple-uarts-in-qemu
+10:03 <@geertu> KVM already works on R-Car Gen3 (like on other arm64 SoCs)
+10:03 < damm> with uarts and QEMU a lot of magic is possible. but i wonder if actual hardware configuration settings will be propagated to the physical port
+10:04 < damm> it is just speculation from my side though
+10:04 <@geertu> damm: I think so, as the QEMU invocation does not specify e.g. baud
+10:04 < damm> on my remote access system i use socat with the host side pty
+10:04 < damm> which does not work with hardware settings
+10:05 < damm> but physical device might work better
+10:05 < damm> anyway
+10:05 < damm> nice to see renewed interest in KVM
+10:06 <@geertu> I don't think it makes much sense to start talking about "how long" and "cost" if the goal is unclear
+10:06 < moriperi> geertu: Yes, indeed.
+10:06 < moriperi> So, as 1st I will ask to Munakata-san about Renesas side plan.
+10:06 < moriperi> Is it OK for you ?
+10:07 <@geertu> Given Google's focus on GKI and making as much as possible platform-independent...
+10:07 < damm> if needed we can try to bridge the gap and make use case proposals
+10:07 < moriperi> Maybe Renesas will think about 202X budget for it.
+10:08 <@geertu> moriperi: That's a valid point. So we need as many wild ideas as possible, to secure budget? ;-)
+10:08 < damm> how about gRPC over virtIO uart to a coprocessor?
+10:09 < moriperi> geertu: sounds nice :)
+10:09 < moriperi> (joke)
+10:09 < moriperi> 1 things he said was that Laurent indicated virt Video related things at elinux.
+10:10 < moriperi> He and TOYOTA had interested about it.
+10:10 <@geertu> I'm indeed not familiar with video virtualization
+10:10 < moriperi> Maybe we need more ping-pong about it over email :)
+10:11 <@geertu> moriperi: Please let laurent recover from 100 to 200% ;)
+10:12 < moriperi> :)
+10:12 < pinchartl> I don't plan to go back to an unsustainable schedule :-)
+10:12 <@geertu> Anything else to discuss?
+10:12 <@geertu> Next meeting?
+10:12 <@geertu> In 3 weeks, is Dec 17. 4 weeks is Dec 24 (Xmas eve)
+10:13 < wsa> 17th
+10:13 <@geertu> So Dec 17 might be better, also considering Jinzai reporting schedule?
+10:14 < wsa> xmas eve is a good reason for 17th, too ;)
+10:14 < shimoday> 17th is ok to me
+10:14 <@geertu> OK
+10:14 <@geertu> Thanks for joining, and have a nice continued day!