From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20190606-io-chatlog | 173 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 wiki/Chat_log/20190606-io-chatlog (limited to 'wiki/Chat_log/20190606-io-chatlog') diff --git a/wiki/Chat_log/20190606-io-chatlog b/wiki/Chat_log/20190606-io-chatlog new file mode 100644 index 0000000..06a1875 --- /dev/null +++ b/wiki/Chat_log/20190606-io-chatlog @@ -0,0 +1,173 @@ +09:05 < wsa> So, let's start the IO meeting +09:05 < morimoto> she can't talk anyway :) +09:05 < neg> Swedish is easy, don't know what you are talking about +09:05 < morimoto> geertu: thanks +09:05 < wsa> as always, the collected reports, let me know if that needs fixing: +09:05 < wsa> A - what have I done since last time +09:05 < wsa> ------------------------------------ +09:05 < wsa> Geert +09:05 < wsa> : reduced delays in the MSIOF driver and looked into USB regression causing +09:05 < wsa> WARNING during second system suspend +09:05 < wsa> Marek +09:05 < wsa> : worked on and sent patch for Gen3 PCIe lockdep issue on root complex removal +09:05 < wsa> Niklas +09:05 < wsa> : got issues with "SDHI runtime PM enablement" resolved and patch was applied, +09:05 < wsa> assisted Wolfram with OOPS debugging +09:05 < wsa> Shimoda-san +09:05 < wsa> : submitted patches to improve SDHI performance with IOMMU, PM and SPDX patches +09:05 < wsa> for PWM, removed unused features in USBHS, fix imbalance powered flag for +09:05 < wsa> USB2-PHY, and handled delays for the WDT, reviewed USB patches dealing with +09:05 < wsa> role switch support, researched removing the r8a66597-udc, and reported a bug +09:05 < wsa> about USB SSD with xHCI +09:05 < wsa> Simon +09:05 < wsa> : posted and merged v4 of Gen3 IPA support and dynamic power coefficient patches +09:05 < wsa> Ulrich +09:05 < wsa> : sent v2 of "ravb: implement MTU change while device is up" +09:05 < wsa> Wolfram +09:05 < wsa> : started to work on converting i2c_new_dummy users, worked on analyzing various +09:05 < wsa> OOPSes, sent out a series improving HS400 quirks, took over add. SDHI task from +09:05 < wsa> Niklas, assisted Shimoda-san with WDT delay cycles and SDHI IPMMU improvements, +09:05 < wsa> picked up "WDT handover after boot" topic again, reviewed RWDT, SDHI, i2c slave +09:05 < wsa> patches +09:05 < wsa> B - what I want to do until next time +09:05 < wsa> ------------------------------------- +09:05 < wsa> Geert +09:05 < wsa> : wants to look into SCIF TX DMA length of 0 issue +09:05 < wsa> Shimoda-san +09:05 < wsa> : wants to continue to discuss SDHI driver with IOMMU, change memcpy() to +09:05 < wsa> assignments in USBHS driver, and investigate imbalance enable/disable +09:05 < wsa> in rcar-gen3-usb2 driver as well as USB SSD issue +09:05 < wsa> Simon +09:05 < wsa> : wants to follow up on RAVB on E3/D3 Errata +09:05 < wsa> Wolfram +09:05 < wsa> : wants to continue with i2c_new_dummy conversion, finalize HS400 quirks patch +09:05 < wsa> series, continue with add. SDHI task, ask for help regarding the workqueue +09:05 < wsa> related OOPS +09:05 < wsa> C - problems I currently have +09:05 < wsa> ----------------------------- +09:05 < wsa> Kaneko-san +09:05 < wsa> : patch "rcar_gen3_thermal: Update calculation" is reviewed but stuck +09:05 < wsa> Wolfram +09:05 < wsa> : got no response from Guenter about the WDT handover topic, needs the +09:05 < wsa> information which Gen3 SoCs cannot do SDHI tap auto correction with HS400 +09:05 < wsa> because this issue crashes M3N with current upstream kernels +09:06 < wsa> about Kaneko-san's patches being stuck, maybe it would help if we add some Tested-by tags? +09:06 < wsa> (I didn't see any in patchwork) +09:07 < wsa> horms: neg: do you have some minutes to do that? +09:08 < horms> wsa: I think I have done so. But perhaps I should repost with those tags? +09:08 < neg> wsa: will do +09:08 < wsa> uli_: David Miller nacked "ravb: implement MTU change while device is up". does his reply show a clear way forward? +09:09 < wsa> horms: I also thought you did... but I couldn't find the tags +09:09 < uli_> depends if i understand him correctly +09:09 < horms> wsa: let me take a look and take some appropriate action +09:09 < wsa> It may be good to resend with tags, and then Niklas can add his as well +09:09 < wsa> horms: thanks +09:09 < uli_> we could reset the mtu if the re-open fails, but then the device may still go down because of an mtu change +09:09 < uli_> in theory... +09:09 < geertu> uli_: I failed to parse his last sentence. +09:10 < uli_> i think there is an if too many at the start +09:10 < geertu> OK, so he wants to revert the MTU change on failure +09:10 < uli_> that's how i read it +09:11 < geertu> Fortunately netdev_update_features() cannot fail (at least it returns void ;-) +09:11 < wsa> how are other drivers handling it? +09:11 < uli_> they aren't, as far as i could tell :) +09:11 < uli_> some implement mtu changes while the device is up, but that is somewhat complex +09:11 < uli_> most just take the device down and up again +09:12 < horms> I think that such a scheme would be an improvement over what we currently have +09:12 < geertu> And, in theory, the ravb_open() after MTU revert might fail, too? +09:12 < uli_> possibly +09:13 < wsa> That sounds like a question for David? +09:14 < uli_> i suppose so +09:14 < wsa> can you take care of that? +09:14 < uli_> i will +09:14 < wsa> thanks! +09:15 < horms> I wonder why a failure might occur and if there is any value in trying to unwind +09:15 < wsa> shimoda: any news which SoCs have the issue with "SDHI tap autocorrection and HS400"? +09:16 < geertu> horms: The device might not support the new MTU value? +09:16 < wsa> (I suppose not, but I still wanted to ask :)) +09:16 < geertu> (e.g. too large) +09:16 < wsa> Last time, Goda-san suggested to wait some time for confirmation from the HW team, I think +09:16 < horms> geertu: sure. its possiible. but the driver should know the max mtu of the device +09:17 < horms> geertu: anyway, I'm just thinking out loud +09:17 < geertu> horms: .ndo_change_mtu() is passed the value from userspace? +09:17 < uli_> i assumed that one if the various initializations may fail (dmac, clock, phy, whatever) +09:17 < wsa> morimoto: I got a mail two weeks ago "peripelist | Access to project was granted". Is there a change in infrastructure? (Maybe I missed some information?) +09:17 < geertu> without checking? +09:18 < morimoto> wsa: I exchanged periject git repository access for periperi people. now all member can push. I guess it is for it ? +09:19 < shimoda> wsa: unfortunately hw team is investigating this issue now +09:19 < geertu> morimoto: I received the access email for peripelist and periupport +09:19 < wsa> morimoto: the mails mentioned "peripelist" and "periupport", not "periject" +09:20 < morimoto> wsa: Oops, "peripelist". I exchanged *not* to push it. +09:20 < morimoto> "periject" : all member can push +09:20 < wsa> shimoda: Ok, I will wait some more. Thanks for the heads up. +09:20 < morimoto> peripelist / periupport : all member can't push +09:21 < wsa> Ah, now I see +09:21 < morimoto> wsa: geertu: I guess no more update for peripelist / periupport, right ? +09:22 < geertu> morimoto: Indeed: GitLab: You are not allowed to push code to this project. +09:22 < geertu> morimoto: Good, we we won't update those anymore ;-) periject rulez! +09:22 < morimoto> I'm sorry I didn't mention +09:22 < morimoto> mention about it +09:22 < wsa> any open questions from your side? +09:24 < horms> geertu: dev_set_mtu_ext() calls __dev_set_mtu() which in turn calls ndo_change_mtu(). dev_set_mtu_ext() also chacks dev->max_mtu +09:24 < geertu> horms: So it's not expected to fail +09:24 < wsa> horms: just to make sure, please drop the SDHI upport for Kaneko-san. We need the info from the HW team before we decide how to continue +09:24 < horms> geertu: I can't say for sure. But that is my reasoning at this point +09:24 < horms> wsa: ack +09:25 < wsa> horms: I see you found some MM upporting tasks for him meanwhile :) +09:25 < horms> geertu: I recall that this kind of helper is a relatively new invention to simplify driver code. So I think the assumption is the check prevents some failure modes. +09:26 < horms> wsa: yes, pinchartl was very helpful +09:28 < wsa> okay, then, I think we are done with this meeting +09:28 < wsa> So, thank you all for your work! +09:29 < pinchartl> regarding periupport, we're still missing support for an equivalent feature in periject... +09:30 < wsa> you mean a visualization of which patch is already processed? +09:30 < morimoto> pinchartl: which feature ?? +09:31 < pinchartl> visualization is one of them +09:31 < pinchartl> but also a way to easily mark patches that we don't want to upstream +09:31 < pinchartl> with a reason +09:31 < pinchartl> in a nutshell, a BSP patch tracker +09:31 < pinchartl> which is exactly what pariupport is +09:31 < geertu> And I need to improve my YAML parsing skills, as my old bash scripts to auto-update upstreamed periupport commits can no longer be used +09:31 < pinchartl> periject being a task tracker +09:32 < morimoto> pinchartl: about visualization, you can merge "viewer" branch +09:32 < morimoto> pinchartl: and do "make". you can find html file again :) +09:33 < pinchartl> that doesn't bring me a list of MM patches from the BSP :-) +09:34 < morimoto> I think it is "idea" issue, not "tool" issue ? How about to add "remain BSP patches" file +09:35 < pinchartl> but BSP patches != tasks ... +09:35 < pinchartl> I don't want to create a task titled "Do not port these BSP MM patches" that refers to BSP patches that I don't want to upport +09:37 < pinchartl> I fully agree that for BSP patches that we want to upport we should create tasks +09:37 < pinchartl> but it's the other ones that we have no good way to handle +09:38 < wsa> The way I handle it: some topics get a dedicated task, like "SDHI: HS400 autocorrection". The leftovers get a task like "bsp395: upport SDHI patches". In there, I can comment on them to be not upported +09:40 < pinchartl> I don't like that much :-( +09:40 < pinchartl> to me periupport is similar to patchwork +09:40 < pinchartl> it tracks commits +09:40 < pinchartl> to make sure none of them gets forgotten +09:40 < pinchartl> while periject is a task tracker +09:42 < morimoto> I don't understand what is the issue ... +09:42 < morimoto> How about this ? +09:42 < morimoto> task name = "sort BSP patches" +09:42 < morimoto> you can list up all remain patches. +09:42 < morimoto> you can use comment or tag or something to mark up. +09:42 < morimoto> pick up them if it could tasks. +09:43 < geertu> Thigns become complicated when combining multiple commits in a single task, with different paths forward +09:43 < pinchartl> that would be like replacing patchwork by a process that adds an entry in a bugzilla titled "Handle patches posted to the mailing list" and then using it to track the state of patches +09:44 < pinchartl> we *could* do something like that, but it's quite a hack, and I don't think it would be very practical +09:44 < wsa> pinchartl: send patches :) +09:44 < pinchartl> wsa: for what ? :-) +09:45 < shimoda> pinchartl: in other words, you'd like to maintain both periupport and periject? +09:45 < wsa> pinchartl: whatever you like +09:46 < pinchartl> shimoda: yes and no. I think the two tools handle different needs. but I also think we could integrate periupport in periject if we wanted to, but in that case we should have a ticket file similar to what we have today in periject +09:46 < pinchartl> (possibly in a different format, we can standardize everything on yaml if we want, but the idea remains the same) +09:47 < geertu> Hence new BSP commits start with being an individual new periject ticket, but may be absorbed/aggreated into a larger task? +09:47 < geertu> s/ticket/task/ +09:47 < pinchartl> geertu: no, I don't think we should create a ticket for each BSP commit +09:48 < pinchartl> BSP commits would be stored in a single file like we do in periupport, and we would create tasks out of them as we plan/perform the backporting +09:48 < pinchartl> one ticket per BSP commit would soon become very, very impractical +09:49 < pinchartl> but in any case I don't think I'll win this fight, as none of us will have time to specify how this would be handled, not even talking about implementing the tooling :-) +09:49 < neg> How about a bsp-commit.txt file similar to periupport, in it one can nack a patch and give a reason. Then add some visualisation of the delta of patches that should be upported but are not listed in any task file ? +09:49 < pinchartl> neg: I think that's what I meant by importing a periupport-style BSP commits file, yes +09:50 < pinchartl> (again, could be in the same format as today, or we could use yaml if we wanted to store everything in yaml) +09:51 < wsa> pinchartl: I don't think it is a fight. It is just about spending time on it as you mentioned +09:52 < pinchartl> wsa: it was just a metaphor, but not the best choice of word, I agree +09:54 < geertu> Time for Core chat? +09:55 < wsa> i think so +09:56 < geertu> ok -- cgit v1.2.3