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!