diff options
| -rw-r--r-- | wiki/Chat_log/20201126-core-chatlog | 111 |
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! |