1 files changed, 202 insertions, 0 deletions
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 <sha1>|<Tn>, with <sha1> replaced by <Tn> 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!