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