path: root/wiki/Chat_log/20210318-core-chatlog

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!