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/20181220-io-chatlog | 202 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 202 insertions(+) create mode 100644 wiki/Chat_log/20181220-io-chatlog (limited to 'wiki/Chat_log/20181220-io-chatlog') diff --git a/wiki/Chat_log/20181220-io-chatlog b/wiki/Chat_log/20181220-io-chatlog new file mode 100644 index 0000000..9bcc8c7 --- /dev/null +++ b/wiki/Chat_log/20181220-io-chatlog @@ -0,0 +1,202 @@ +09:05 < wsa> welcome to the last IO meeting this year +09:05 -!- horms [~horms@2400:2650:39e2:a000:c685:8ff:fe7c:9971] has joined #periperi +09:05 < wsa> here are the status updates: +09:05 < wsa> Status updates +09:05 < wsa> ============== +09:05 < wsa> A - what have I done since last time +09:05 < wsa> ------------------------------------ +09:05 < wsa> Geert +09:05 < wsa> : resubmitted fixes for fallback to PIO in the sh-sci driver +09:05 < wsa> Kaneko-san +09:05 < wsa> : got r8a77990 I2C SYS-DMAC enablement merged +09:05 < wsa> Marek +09:05 < wsa> : adjusted the thermal API to handle per-driver parameters and converted drivers +09:05 < wsa> to use it, also reposted PCA953x PM patches +09:05 < wsa> Niklas +09:05 < wsa> : got all HS400 patches in an upstream tree merged (except for the final DT patch) +09:05 < wsa> Shimoda-san +09:05 < wsa> : investigate the PWM backlight issues and submitted a workaround patches, +09:05 < wsa> submitted an explanation of USB virtualization for eLinux, reviewed RZ/G2E USB +09:05 < wsa> related patches, investigating an issue that USB3 peripheral's transfer stops +09:05 < wsa> unexpectedly if g_ether/g_ncm is used, and investigate an issue that SCIF5 on +09:05 < wsa> R-Car E3 doesn't work with SYS-DMAC +09:05 < wsa> Simon +09:05 < wsa> : posted RAVB phy-mode and no-link patches for Ebisu and posted an RFC to fix +09:05 < wsa> the RAVB rx csum VLAN issue +09:05 < wsa> Wolfram +09:05 < wsa> : sent out two new series for I2C core suspend handling, implemented two scripts +09:05 < wsa> to convert data to periject, further discussed and reached agreement about +09:05 < wsa> watchdog suspend/resume handling and documented it properly, review of various +09:05 < wsa> patches including Marek's thermal series, looking for and sending out +09:05 < wsa> stalled 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 resubmit final patch for fallback to PIO in the sh-sci driver +09:05 < wsa> Kaneko-san +09:05 < wsa> : wants to +09:05 < wsa> Marek +09:05 < wsa> : wants to handle the thermal patchset feedback +09:05 < wsa> Shimoda-san +09:05 < wsa> : wants to ping the PWM maintainer if needed and continue to investigate +09:05 < wsa> the USB3 peripheral + g_ther/g_ncm issues +09:05 < wsa> Simon +09:05 < wsa> : wants to follow-up on RAVB rx csum for VLAN patch +09:05 < wsa> Wolfram +09:05 < wsa> : wants to keep at the I2C core suspend handling series, check upstream SDHI bug +09:05 < wsa> report about accessing large files, work on known IIC issues, upport I2C/SDHI +09:05 < wsa> patches +09:05 < wsa> C - problems I currently have +09:05 < wsa> ----------------------------- +09:05 < wsa> Simon +09:05 < wsa> : needs testing for his RAVB rx csum for VLAN patch +09:05 < wsa> Wolfram +09:05 < wsa> : got no response for my bsp-ticket-file to periject converter and no response to +09:05 < wsa> the mail I sent to the MM team about GMSL +09:06 < wsa> Kaneko-san's B) is still open because I wondered about the PWM on E3 (c.f. my mail) +09:06 < wsa> horms: you are waiting for the tests from the BSP team, right? +09:07 < horms> Yes. I can push the patch without such tests. But I'd rather not +09:08 < wsa> I agree +09:09 < wsa> shimoda: can you gently ping BSP team and/or Jinzo to test this patch? +09:10 < wsa> Marex: when do you think will the PCIe ATF code be upstream? +09:10 < shimoda> wsa: sorry, about what? +09:10 < wsa> shimoda: about the patch simon created for "[periperi] Cannot receive a Q-Tag VLAN flame on the ravb driver (#194782)" +09:11 < wsa> Marex: any rough estimate? +09:11 < Marex> wsa: as soon as I rework the patch on top of upstream ATF EA changes +09:11 < Marex> wsa: and then there's gonna be discussion for sure, since it's a bit controversial ... February-ish ? +09:12 < wsa> Marex: okay, thanx! +09:12 < shimoda> wsa: Jinso test team already tested the patch, so I believe he can submit Tested-by. So, I'll ask him. Also, I'll ask BSP team when they can test it. +09:12 < wsa> shimoda: ah, good news :) +09:12 < Marex> wsa: my understanding is that syncing upstream ATF with renesas ATF has higher prio, which is what I'm working on now +09:13 < wsa> Marex: I see, makes sense +09:13 < wsa> jmondi is not here now, so I'll skip the GMSL question for now +09:14 < wsa> geertu: about TDSEL, latest news look like we can implement initializing TDSEL for early ES versions. D'accord? +09:15 < geertu> wsa: Yeah, looks like that +09:15 < wsa> So, I could resend those with proper soc_device_match()? +09:15 < geertu> Yes please +09:15 < wsa> cool +09:15 < Marex> wsa: btw there's another ATF topic where upstream is concerned about renesas stuff -- whether the ATF code is properly locked out and cannot be read by later stages -- I need to check that +09:15 < horms> shimoda: thanks! +09:16 < wsa> Marex: yes. but that's more core stuff, or? +09:17 < wsa> any more IO related questions from your side? my next questions deal with periject, so I'd like to have technical discussions before that +09:17 < Marex> wsa: ask geertu :) +09:17 < wsa> :D +09:17 < Marex> wsa: I have a feeling U-Boot and ATF is kinda on the side and outside of the usual split :S +09:19 < wsa> kbingham: you there? +09:19 < wsa> pinchartl: and you? +09:19 < pinchartl> wsa: I am +09:20 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit Ping timeout: 250 seconds +09:20 < wsa> so, I wrote those two scripts. the second one needing a bugfix, still +09:20 < wsa> but in general, was it that what was desired? +09:21 < wsa> what are the next periject steps if so? +09:21 < pinchartl> I still need to check the second script +09:22 < pinchartl> regarding next steps +09:22 < pinchartl> we likely need a query tool +09:22 < pinchartl> but I think that can be developed as we go +09:22 < pinchartl> what I think is needed is proper integration of validation in the git commit hook +09:22 < pinchartl> and probably on the server side too +09:23 < pinchartl> I think it was Simon who raised the issue that uuids are not very usable (and I believe we pretty much all agree) +09:23 < pinchartl> so I think we should also try to replace that with a global ID at commit/push time +09:24 < pinchartl> I'm not sure if that can be done on the server side or just on the local side +09:24 < pinchartl> apart from that, I think we're ready to give it a try +09:24 < horms> (I don't think it was me) +09:25 < pinchartl> ok, could have been someone else :-) +09:25 < wsa> yes, i recall consensus that the unique-key should be generated at push-time +09:25 < pinchartl> one option would be this +09:25 < pinchartl> we create a file in the root directory of the git tree +09:26 < pinchartl> containing the next ID +09:26 < pinchartl> at commit time, a git hook could +09:26 < pinchartl> - fetch the latest version +09:26 < pinchartl> - increase the ID to reserve as many IDs as needed +09:26 < pinchartl> - push with non-fast-forward denied +09:27 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi +09:27 < pinchartl> - patch the content locally to replace uuids with ids +09:27 < pinchartl> - push +09:27 < pinchartl> that wouldn't require server-side hooks +09:27 < geertu> And if the push fails, retry? +09:27 * kbingham[m] just woke up... +09:28 < pinchartl> geertu: if the push fails it means there was a race, so retry +09:29 < wsa> why can't we use the sha from the commit? +09:30 < kbingham> I can't believe a uuid is any less unique than a sha1? +09:30 < pinchartl> wsa: it's not about unicity, it's about +09:31 < pinchartl> "can you look at ticket 37 ? I think it duplicates 31" +09:31 < pinchartl> vs. +09:31 < wsa> i see +09:31 < pinchartl> "can you look at ticket e2ebc538-9ca3-4cab-ac9f-70563fb95b40 ? I think it duplicates 97a5e041-7835-4a20-ab53-3d16c10081e3" +09:32 < kbingham> Oh - those ids :) +09:34 < wsa> but we all should be used to sha1 with abbrev 14? +09:34 < wsa> :) +09:34 < Marex> wsa: git will soon switch to sha256, so that might be a good idea :) +09:34 < geertu> They're as easy to remember as recent Renesas SoC part numbers ;) +09:35 < horms> I believe a key requirement of the project, which lead us to develop it rather than reuse an existing system, was for offline access. Thus the attraction of a sha, uuid, or similar +09:35 < wsa> morimoto: do you know when/if there will be a new ticket file? ticket file is "bsp370" but latest bsp is 3.9.2 +09:35 < geertu> We could start with sha1s, and run (atomically) a script to replace them by generated numbers at mdnight? +09:36 < pinchartl> horms: I think combining guids and global ids would be a good way to ensure both usability and offline access +09:36 < kbingham> Would that rewrite history ? or just do some magic to append a commit on top giving the id a number? +09:36 < pinchartl> we start with guids for anything new created locally +09:36 < geertu> So you can work offline, and once in a while the new commits get assigned an simpler ticket number (mapping file) +09:36 < kbingham> And if it's just a commit on top - couldn't that already 'just work' ? +09:36 < pinchartl> and they're replaced with ids when you push (which implies that you're online) +09:37 < pinchartl> kbingham: it could apply a commit on top +09:37 < pinchartl> or, as I explained, patch locally before pushing, in a local git hook +09:37 < pinchartl> I don't know if we can get access to server-side hooks +09:37 < geertu> When using a sha1, it would refer to the the sha1 of the original ticket at creation time anyway, while the ticket file itself can change later, right? +09:37 < pinchartl> or even whether server-side hooks would actually work best for what we're trying to do +09:37 < horms> pinchartl: fine, so long as there isn't a requirement to refer to gloabl ids before they are available - e.g. latency when using the debian bugtracker (maybe fixed by now) +09:38 < pinchartl> horms: I don't think we'll refer to guids in a shared environment anyway. if the guids are used locally and then patched when you push, you will have an id available as soon as the content is available to others +09:38 < geertu> I.e. all references can be to |, with replaced by over time +09:39 < pinchartl> so you would only need to use the guid during discussions if you want to refer to a ticket that hasn't been pushed yet +09:39 < pinchartl> which would cause the other party to have trouble looking at it anyway :-) +09:39 < horms> makes sense +09:40 < wsa> :) +09:40 < geertu> s/sha1/uuid/ to your liking +09:40 < pinchartl> geertu: or s/uuid/sha1/ +09:41 < geertu> "s" stands for symmetry ;-) +09:41 < pinchartl> :-) +09:41 < pinchartl> the issue with using sha1 is that they're not available before you coommit +09:41 < pinchartl> commit +09:41 < pinchartl> so if you want to commit two new tickets in one go, that refer to each other, it won't be possible with a git sha1 +09:42 < pinchartl> (whether we want to allow that is another question, but there could be other similar valid use cases) +09:42 < geertu> Do you need to have the sha1 of the ticket file before you add he ticket file? Or are all references added later? +09:42 < pinchartl> that's why we went for guid instead +09:42 < geertu> OK +09:42 < pinchartl> but if they're patched as soon as you push, I don't think that's a bit problem +09:42 < pinchartl> it will be very temporary +09:42 < morimoto> wsa: sorry for my late response. I don't know. I will ask to BSP team +09:42 * geertu discovers R-Car M3-W+ +09:42 < pinchartl> we could actually make it even simpler +09:42 < pinchartl> - have a serial number file containing the next ID +09:43 < pinchartl> - create tickets, allocate IDs from that file +09:43 < pinchartl> - at push time, fetch first, then compute the diff between local ID and server ID +09:43 < pinchartl> - increase all new local IDs by the diff +09:43 < pinchartl> (patching new tickets) +09:43 < pinchartl> - push +09:43 < pinchartl> something like that +09:43 < pinchartl> so we wouldn't need guids +09:44 < pinchartl> but the ids would only become meaningful globally when we push +09:44 < pinchartl> using guids as temporary ids makes it clear that they're temporary +09:44 < pinchartl> so it might be better +09:44 < geertu> That would be an additional commit on top, or an ammendment of the existing commits? +09:44 < pinchartl> (although we could prefix temporary numerical ids without something to make that clear too) +09:44 < geertu> The former makes it confusing if you look at history (oh, this old reference to #4 is now actually #7) +09:45 < pinchartl> if we run all this process on the client side, it would be nice if the scripts could rewrite the history +09:45 < geertu> The latter makes it impossible to share early with a team member (non-rebasing policy) +09:45 < pinchartl> if we run hooks on the server side it would likely need to be commits on top +09:46 < geertu> So there needs to be a clear distincation between temporary and final IDs +09:46 < geertu> (e.g. uuid or Tn for temporary, #n for final) +09:47 < pinchartl> it could be as simple as using T#n vs. #n, yes +09:47 < geertu> s/distincation/distinction +09:47 < pinchartl> or ~n, or whatever +09:49 < pinchartl> does this make sense ? +09:49 < geertu> yes, it does to me +09:49 < kbingham> pinchartl, We're looking forwards to the prototype :) +09:50 < geertu> Be prepared to discover bugs in the git hook implementation? ;-) +09:50 < pinchartl> I guess it's fair to assign it to me this time :-) +09:51 < pinchartl> I won't have time before the holidays though +09:51 < wsa> i'll update my second script before the holidays +09:51 < kbingham> It doesn't sound like it would take /too/ long to sketch out. +09:52 < pinchartl> kbingham: no, it shouldn't take /too/long +09:55 < wsa> so, we can conclude this io/periject meeting? +09:55 < pinchartl> I think so +09:55 < wsa> me too +09:56 < wsa> thank you everyone! -- cgit v1.2.3