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]