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