From 7d2c3cc9ebee14ddfa8590431babb1ee06e7693d Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 18 Mar 2021 11:00:00 +0100 Subject: wiki: Add Core chatlog for 2021-03-18 Signed-off-by: Geert Uytterhoeven --- wiki/Chat_log/20210318-core-chatlog | 139 ++++++++++++++++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 wiki/Chat_log/20210318-core-chatlog (limited to 'wiki/Chat_log/20210318-core-chatlog') 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! -- cgit v1.2.3