1 files changed, 139 insertions, 0 deletions
diff --git a/wiki/Chat_log/20210318-core-chatlog b/wiki/Chat_log/20210318-core-chatlog
new file mode 100644
index 0000000..750f326
--- /dev/null
+++ b/wiki/Chat_log/20210318-core-chatlog
@@ -0,0 +1,139 @@
+09:23 < geertu> Welcome to today's Core Group Chat Meeting!
+09:23 < geertu> Agenda:
+09:23 < geertu> 1. Status Updates
+09:23 < geertu> 2. Discussion Topics
+09:23 < kbingham> wsa, aha, got it ? ;-)
+09:23 < geertu> Topic 1. Status updates
+09:23 < geertu> A) What have we done since last time:
+09:23 < geertu> Marek worked on ATF (upporting Renesas downstream ATF fork v3.0.0) and
+09:23 < geertu> CI (A/B switcher code for R-Car Gen3 using PMIC).
+09:23 < geertu> Niklas submitted patches for the R-Car V3U thermal and R-Car H3
+09:23 < geertu> ES1.x TMU clocks, and for R-Car Gen3 vin4_g8 and vin5_high8 pins.
+09:23 < geertu> Shimoda-san continued investigating R-Car V3U IPMMU + SYS-DMAC issues,
+09:23 < geertu> and supported the BSP team about R-Car V3U CPU/PMU DT, and the customer
+09:23 < geertu> Q&A team about DT licensing.
+09:23 < geertu> Geert worked on merge window investigations, added pin bias support for
+09:23 < geertu> R-Car M2 and Koelsch, consolidated the Salvator-X(S) HDMI description in
+09:23 < geertu> DT, restructured Falcon DTS files to match board stack, started looking
+09:23 < geertu> into dynamic frequency/voltage scaling, and did more periject bsp-41x
+09:23 < geertu> core triage.
+09:24 < geertu> B) What we plan to do till next time:
+09:24 < geertu> Marek plans to continu working on CI (improve A/B switcher with WDT and
+09:24 < geertu> MFISBTSTSR support), and considers adding a WDT driver to U-Boot.
+09:24 < geertu> Shimoda-san plans to continue working on IPMMU for R-Car V3U, and hopes
+09:24 < geertu> to collect more information about R-Car Gen3e.
+09:24 < geertu> Geert plans to send pull requests for v5.13, and continue dynamic
+09:24 < geertu> frequency/voltage scaling for R-Car Gen3(e), bsp-41x triage, and perhaps
+09:24 < geertu> add pin bias support for other R-Car Gen2 SoCs and boards.
+09:24 < geertu> C) Problems we have currently:
+09:24 < geertu> Morimoto-san realizes he's becoming older.
+09:24 < geertu> Geert is worried about Renesas blocking some patch emails.
+09:24 -!- morimoto [~user@2001:268:c142:cda5:f440:7c6:e45a:6f9b] has quit [Ping timeout: 244 seconds]
+09:25 < geertu> and irc?
+09:25 < geertu> --EOT--
+09:25 < geertu> Anything I missed?
+09:26 < geertu> Is there something special with the address hoang.vo.eb@renesas.com, that my patch CCed to it was rejected?
+09:26 < marex> geertu: I;ve had that a few times with internal addresses too
+09:26 < damm> it looks like the characters might be byteswapped?
+09:27 < geertu> damm: bitflipped, you mean? ;-)
+09:27 < patersonc> geertu: if it helps, according to my outlook that person/email exists
+09:28 < damm> ok then i take it all back =)
+09:29 < geertu> patersonc: It claims to be blocked by a custom mail rule "rejected by organization policy"
+09:29 < shimoday> geertu: i don't know why. hoang-san is still in Renesas vietnam
+09:29 < patersonc> Maybe he's not allowed contact with the outside world ;)
+09:30 < morimoto`> ahh, vietnam member has some kind of network limitation
+09:30 < shimoday> so, I'll ask someone about this issue with the report which you wrote
+09:30 < geertu> shimoday: mail for khiem.nguyen.xt@renesas.com doesn't bounce
+09:30 < patersonc> geertu: He's special
+09:31 < geertu> shimoday: thx!
+09:31 < shimoday> geertu: thank you for the addtional information. I'll ask later
+09:31 < geertu> Topic 2. Discussion Topics
+09:31 < geertu> A) UIO
+09:32 < geertu> People are intrigued and worried with the BSP containing patches to enable UIO for various devices, and declare native Linux drivers "legacy"
+09:34 < geertu> Any comments for japeri?
+09:34 < wsa> I hope this is just OSAL terminology and not BSP team's
+09:36 < neg> OSAL ?
+09:36 < shimoday> geertu: sorry i don't have any update after I sent email... perhaps, we should ask OSAL team (and BSP team) about thier plan...
+09:36 < wsa> neg: "OS abstractio layer"
+09:36 < neg> wsa: Ahh, thanks
+09:37 < wsa> I'd be much surprised if the BSP team does not also have customers with use cases which need kernel driver for these devices?
+09:38 < wsa> or is that naive thinking?
+09:38 < pinchartl> it would be useful to know the plan, yes
+09:38 < damm> is it Operating System or Open Source in OSAL?
+09:40 < damm> As for UIO, last time I checked it was not a very good solution for bus mastering devices
+09:40 < damm> since user space may break kernel space via DMA
+09:41 < marex> damm: doesnt iommu help prevent that ?
+09:41 < damm> Perhaps they are considering this for RTOS use?
+09:41 < damm> I suppose IOMMU could be used to give protected address spaces to user space
+09:42 < damm> It is a bit hard for me to imagine how zero copy buffer handling would work in such setup though
+09:42 < marex> I guess it can be used to limit what the DMA can damage, and then you might end up with userspace drivers, like the GPU blob, which is basically a userspace DMA-device driver :-(
+09:43 < shimoday> damm: I think so that they would like to use some software on other OS like QNX
+09:43 < pinchartl> marex: or the codec drivers
+09:43 < marex> damm: maybe like with GPU BOs, make the BO into one address space, do your business, unmap, map elsewhere
+09:43 < marex> pinchartl: m2m v4l ?
+09:44 < pinchartl> not the Renesas codec drivers I'm afraid. they're in userspace with a kernel shim
+09:45 < damm> so with IOMMU i guess we can assume UIO can safely support exposing devices to user space
+09:45 < damm> and we can use runtime pm with open/close for some level of power management
+09:46 < damm> and as long as interrupts are unique they can be forwarded to user space in a generic way
+09:46 < damm> so from a techincal point of view it might very well work
+09:47 < damm> but i do not think it is a suitable replacement for proper device drivers
+09:47 < damm> but say for initial prototyping or on other operating systems
+09:47 < marex> smells like a microkernel approach
+09:47 < damm> i dont see what would be wrong
+09:47 < damm> sure
+09:47 < pinchartl> damm: it would be nice to know more about Renesas's plans in this area
+09:48 < marex> I agree
+09:48 < pinchartl> and whether  we should all take vacations instead of bothering with kernel drivers
+09:48 < geertu> Yes, there's a difference between "it can be done, technically", and "it should be done"
+09:48 < shimoday> damm: JFYI, according to the bsp, IPMMUs also seem to become UIO... :)
+09:48 < damm> i completely agree with all of you =)
+09:49 < damm> ouch, i pressed enter before i saw IPMMU and UIO in the same sentence
+09:49 < shimoday> anyway, we should get Renesas plan about the OSAL.
+09:49 < wsa> pinchartl: no vacation please, you could work on SDHI ;)
+09:50 < damm> the OSAL idea pops up here and there every now and then
+09:50 < damm> for user space i tend to suggest people to use a subset of posix instead
+09:50 < geertu> damm: But this time the (rc8) BSP disables devices for Linux actively
+09:50 < pinchartl> wsa: you'll need to up the offer a little bit, I'm more tempted by vacation at this point :-)
+09:51 < geertu> pinchartl: confined at home? ;-)
+09:51 < pinchartl> geertu: sleeping
+09:51 < neg> No time for vacations right, it will be quadruple the work to do both legacy and UIO drivers, right? ;-)
+09:52 < damm> do we known which devices that are targeted for UIO/OSAL?
+09:52 < geertu> damm: git grep uio rcar-4.1.0.rc8 -- arch/arm64/boot/dts/renesas/
+09:53 < geertu> Add "-B1" and see the node names, too
+09:54 < geertu> IMP, VIN (shared with "legacy"), IPMMU, ISP, VSP (shared), CSI (shared), DU (shared), LVDS (shared)
+09:54 < pinchartl> I can't help feeling that some of us are more targetted than others :-)
+09:54 < geertu> ICCOM, IVP, WWD, FBC, FBA, RTFSO, IMR
+09:55 < wsa> RTFSO? :D
+09:55 < geertu> STV, DOF, FCP, ACF, DSI
+09:56 < geertu> pinchartl: Linux MM must be too hard?
+09:56 < geertu> Next topic?
+09:56 < geertu> B) R-Car Gen3e
+09:57 < geertu> From Shimoda-san's status report, I guess there's no new info to share?
+09:57 < jmondi> it would have been faster to list the devices not affected by UIO/OSAL :)
+09:57 < damm> Seems to be mainly in M/M space i guess
+09:59 < damm> Perhaps the topic of UIO/OSAL for such devices can be carried over to the M/M meeting?
+09:59 < shimoday> geertu: unfortunately, i don't have any update. on a plan, doc releases at end of March
+09:59 < geertu> shimoday: ok, thx
+09:59 < geertu> C) RZ/G2L
+10:00 < marex> finally open GPU driver
+10:01 < pinchartl> regarding RZ/G2L
+10:01 < damm> yeah nice
+10:02 < pinchartl> we have recently received patches for the VSP driver
+10:02 < pinchartl> but it doesn't seem that documentation is available ?
+10:02 < pinchartl> or have I missed it ?
+10:02 < pinchartl> it was difficult to review the patches without knowing about the hardware
+10:03 < geertu> patersonc: ^
+10:03 < patersonc> Good point. I'll get the current h/w manual out to you
+10:03 < patersonc> Nag me if you don't see it today
+10:04 < pinchartl> thank you
+10:05 < geertu> Anything to add?
+10:06 < geertu> (I think RZ/G2L is more a ukperi than japeri topic anyway?)
+10:06 < geertu> Next meeting?
+10:07 < wsa> April, 15th?
+10:07 < geertu> April 15?
+10:07 < geertu> bingo ;-)
+10:07 < wsa> :)
+10:08 < pinchartl> works for me
+10:08 < shimoday> april 15th is good to me
+10:08 < geertu> OK
+10:09 < geertu> Thanks for joining, and have a nice continued day!