From a00ba95cc2aaf74178c06fcf04f522156bfd61a2 Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Fri, 19 Feb 2021 08:01:00 +0900 Subject: wiki: Add I/O chatlog for 2021-02-18 Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20210218-io-chatlog | 225 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 225 insertions(+) create mode 100644 wiki/Chat_log/20210218-io-chatlog (limited to 'wiki/Chat_log') diff --git a/wiki/Chat_log/20210218-io-chatlog b/wiki/Chat_log/20210218-io-chatlog new file mode 100644 index 0000000..8ba74c7 --- /dev/null +++ b/wiki/Chat_log/20210218-io-chatlog @@ -0,0 +1,225 @@ + so, welcome to the io meeting and here are the status updates: [16:54] + 'morning everyone +*** damm (~damm@l193216.ppp.asahi-net.or.jp) has joined channel #periperi + A - what have I done since last time + ------------------------------------ + Geert + : fixed PHY Runtime PM in SH-ETH and related improvements for SMSC911X, + added Falcon I2C EEPROM support + Niklas + : resent Gen3 timer patches, discussed V3U timer support + Shimoda-san + : added mmc aliases to Gen2/3 board files, investigated RPC-IF driver + issues with BSP team, got some information about Gen3e + Ulrich + : sent atomic xfer support for i2c-rcar + Wolfram + : upstreamed V3U support for WDT, I2C, AVB0, SDHI, (H)SCIF for 5.12, + investigated issues of AVB1-5 and RPC-IF on the V3U Falcon board, sent + I2C core preparations for extended RECV_LEN sizes, improved I2C testunit + with RECV_LEN testcase, moved already rejected patches from new BSP list + to the non-target list, enabled WAIT_WHILE_BUSY and removed + NON_REMOVABLE workaround for SDHI + B - what I want to do until next time + ------------------------------------- + Geert + : wants to revise Falcon I2C EEPROM support + Niklas + : wants to figure out number of TSC nodes on V3U + Shimoda-san + : wants to continue to investigate SDHI driver's issues, collect more + information about R-Car Gen3e, continue to develop R-Car S4 Ethernet + driver [16:55] + Wolfram + : wants to pick up "logic analyzer via isolated CPU" work again, + upstream CMT and TMU support for V3U, continue with extended RECV_LEN + and its R-Car support, keep working on SDHI issues + C - problems I currently have + ----------------------------- + None reported. + uli__: is this audio task a big one? Because I wanted to talk about a + (hopefully) small RAVB task and am curious when I can get back to you? + that's not a problem + marex: what can we do to push the PCI L1 issue? Resend the patch? + [16:56] + wsa: probably disable L1 altogether + uli__: okay. so, i'll send you a mail with the details later. [16:57] + wsa: and if someone needs it in the BSP, then there can be a + downstream BSP patch which enables it for special cases where it might + work OK + unconditionally? or just for some devices? + ok, thx + wsa: but it seems for the generic case, which maintainers seems to + care about, L1 is unusable + caring for the generic case sounds OK to me [16:58] + so we should disable it? + the question is whether it is OK to just disable L1 altogether [16:59] + right + I guess we are out of options anyway + FTR, I got the interupt crash during PCIe resume on M3-W again + earlier this week + shimoday: do you want to discuss this with the BSP team? [17:00] + geertu: with what PCIe card and on which CPU core ? + As it's not easy to reproduce, it might be hard to see if disabling + L1 helps + shimoday: if we should disable L1 on PCIe upstream because that's what + the maintainers prefer + geertu: neg: thanks for testing the SDHI workaround removal patch. Much + appreciated! [17:01] + marex: e1000e: Intel(R) PRO/1000 Network Driver + I'm happy to see that quirk gone ;-) + neg: hopefully it will stay "gone" this time [17:02] + wsa: BSP team can keep the patch which handles the link resume [17:03] + marex: No idea which CPU core + wsa: although maybe it is just safer to turn off the L1 states in the + BSP too + geertu: do you have the backtrace ? + marex: exactly, maybe they want to support the generic case, too ;) + [17:04] + okay, are there questions / comments from your side? + wsa: i think we don't need to discus with BSP team because it's the + maintainers prefer so BSP team will have no objection, i guess + i have one periject topic but I want this last + marex: can you prepare a patch then? [17:05] + shimoday: do you happen to have customers that might need L1 link + states ? + for whatever reason + geertu: sorry for my late response. Haha :) it is interesting way + to increase for me :) [17:06] + marex: It's the same/similar one as + https://lore.kernel.org/linux-pci/CAMuHMdX_ksY_AnaGyL0Z4HjUv72ndRM7XsRHkSKaBP7J-xmN1A@mail.gmail.com/ + [17:08] + geertu: makes me wonder whether the spinlock in atf doesn't quite + lock, uh [17:09] + marex: oh right, could be a bug in atf ;-) + the entire gen3 L1->L0 code should be serialized + or better :-( + hopefully not in such fundamental primitives [17:10] + marex: hmm, it's a difficut thing. I don't have any idea how way is + better for now... + I guess, at least for upstream, we should disable L1 [17:12] + BSP team then can decide if they want to pick it + so, for my periject topic [17:13] + wsa: i agree + wsa: I guess we have no other options anyway + let's wake some MM members first: kbingham[m] jmondi pinchartl neg :) + and if BSP team needs the patch, it was posted [17:14] + wsa, Hey I felt that + :-) + some ppl said they want to add patches to the new "non-target" list + kbingham: good \o/ + zZzZ ;-) [17:15] + I propose that we add the reason in brackets '()' for now + Otherwise we start looking at the same patches again for patches which + won't make it upstream but are still kept in the BSP [17:16] + I couldn't think of a better way to maintain this information for now + (please shoot if you can think of one) + g [17:17] + sorry, my dauther typed this 'g' ;) + wsa: You mean like + + - d8c1fb49de142298c345bd112fbad2b26cac9013 # arm64: dts: r8a77990: + Change IPMMU-MM and IPMMU-caches order in DT (These are provisional + patches. Please refer to https + //patchwork.kernel.org/patch/10157459/) + It needed some yes + argh + yes + shimoday: Good. next important keys are "e", "e", "r", and "t" ;-) + [17:18] + It needed some AWK scripts to port this information from good old + periupport, but it moved quite some patches away + wsa: I don't wake up before 11:00 :-) + geertu: :) [17:19] + pinchartl: This is why we discuss all important things before 11:00 ;) + wsa: What exactly do you mean by "add patches ... to the list"? + is this for understanding why patches are rejected too? [17:20] + geertu: basically, if you add an entry to the non-target list + in MM, we have rejected patches in the past, but of course BSP team + still 'need/want' them, so they are there again in this latest bsp + ticket. + wsa: patched moved from upport request, or also for random other + patches we discover in the bsp? + kbingham: Right. And sometimes for years, so it may be forgotten if this + could be upported or was already rejected. [17:22] + I had this with some RAVB patches which Simon back then already tried + upstreaming but they were rejected upstream + kbingham: sorry for lack information. the current bsp-41x list is + from just the bsp, not thier want/need because + But I had to find this out digging through mail threads + they are busy to make such "need/want" list for bsp-410... + so, we need re-reject such patches again [17:23] + shimoday: Do they also plan to take our comments into account? E.g. + [17:24] + spi: sh-msiof: Add MSIOF module clock changing processing for R-Car + Gen3 (Proposing 'N' Should use "assigned-clocks" and + "assigned-clock-rates" in board DTS file that actually uses MSIOF) + and to avoid digging through old mails, I'd like to collect the + information somehow + geertu: that might be another benefit [17:25] + wsa: OK, I'll update the recent changes I made to + bsp-41x-non-target.yaml + It may not be the best format; I guess updating from one BSP list to the + next one is probably still some strange scripting [17:26] + geertu: what is "into account" mean? +* jmondi catches up with the discussion + but as people want to start filling the "non-target" list, it might be a + start at least + shimoday: replace the BSP way by the suggestion in the comment + wsa: geertu: was the sweep you made to the ticket a manual process or + do you have scripts that identify patches that were rejected and + re-purposed in the new ticket ? [17:27] + jmondi: the one marked (patch-id) and (summary) where done by some + half-baked scripting [17:28] + jmondi: for porting the comments from periupport, I wrote scripts to + identify patches based on $subject + run "git path-id --stable" and "git log --oneline" on all commits + upstream and in the BSP, and look for matches + s/path-id/patch-id/ [17:29] + s/where/were/ + wsa: geert: I see, everyone has its own method it seems [17:30] + jmondi: It was similar to what I do for my regular "Auto-update + sweep", which considers patch-id and lore link + jmondi: well, the port from periupport is done now [17:31] + now it is about porting from one bsp-list to the next + yeah sure, I was thinking about moving to one BSP list to anther, and + mostly for future tickets + anyway, thanks, it's not a huge number of patches, and some scripting + + some manual verification should do [17:32] + hopefully so + when backporting upstream patches, BSP team adds lines like + "cherry-picked from: ..." to the description [17:33] + that would be nice for cherry-picking old BSP patches, too, I'd think + [17:34] + if the BSP team is up for it + that said, matching on $subject worked quite well + OK, I think we can close this now? [17:35] + and move to core? + wsa: so we can match on the 'cherry-picked from' ? + wsa: Indeed, Shimoda-san did that in 4d75bd75ef222375 ("linux: + bsp-41x: Move cherry picked commits to non target") + between tickets I mean + jmondi: yes + jmondi: If the cherry-picked points to a commit in upstream or + stable. + I.e. if "git tag --contains v5.11" prints v5.11 [17:36] + (stable needs more checks, as there are more trees) [17:37] + oh I thought wolfram was suggesting, in case the patch has not been + upstreamed, to point to the commit id in the previous bsp ticket + so we can easy get to the status assigned to the patch in the + previous ticket [17:38] + Oops, I missed that detail + anyway, please move to core, I don't want to continue interrupting + the meeting + So yes, then we have to look at what cherry-picked points to for + sure! + geertu: ready? [17:39] + wsa: it can point to a commit in upstream, stable, or another BSP + version. + geertu: right [17:40] + I believe a new BSP is created by rebasing, not by cherry-picking? + (yes, technically, it's the same) + I wouldn't want to solely rely on "cherry-picked from" anyhow [17:42] + agreed + It is nice if the BSP teams helps + but we should be able to act independently from that IMO [17:43] + so, core now? [17:44] -- cgit v1.2.3