Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 131 insertions, 0 deletions

diff --git a/wiki/Chat_log/20151207-io-chatlog b/wiki/Chat_log/20151207-io-chatlog
new file mode 100644
index 0000000..5d6d732
--- /dev/null
+++ b/wiki/Chat_log/20151207-io-chatlog
@@ -0,0 +1,131 @@
+--- Log opened Mon Dec 07 08:53:46 2015
+08:53 -!- wsa_ [~wsa@p4FE25C23.dip0.t-ipconnect.de] has joined #periperi
+08:53 -!- Irssi: #periperi: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal]
+08:53 -!- Irssi: Join to #periperi was synced in 0 secs
+08:54 < wsa_> hello!
+08:54 < geertu> Hi Wolfram
+09:02 < horms> hi
+09:02 < wsa_> hey guys!
+09:02 < wsa_> so, only morimoto-san missing...
+09:05 < wsa_> simon, is your upport-todo-list only for your planning or is it also used to generate reports to Renesas?
+09:06 < horms> Generally the reports I generate are based on a slightly different take on the data
+09:07 < horms> but I am hoping to re-use the todo-list for part of my report writing
+09:07 < horms> does that answer the question?
+09:07 < wsa_> so, from a reporting POV, it doesn't make sense if I copy the IO related entries into my list?
+09:08 < horms> ok, I understand the question
+09:08 < horms> with the upporting todo list you can assume that I will be reporting on those items in some form, so they won't be unreported
+09:08 < wsa_> ok
+09:08 < horms> but if you also wish to report on them I personally don't see a problem with that
+09:09 < wsa_> i didn't want things to be unreported, but I also don't want stale data
+09:09 < horms> agreed
+09:09 < horms> i also plan to report on the integration todo list
+09:09 < horms> so those items shouldn't be left unreported either
+09:10 < wsa_> great!
+09:10 < horms> i think there is quite some overlap between those two lists and the work of other teams
+09:10 < horms> but i don't see much of a problem with that at this time
+09:10 < wsa_> i agree
+09:11 < wsa_> like with SPI slave; there is a patch in the BSP, but I think the upstream solution will look quite different
+09:11 < wsa_> so, two action items make sense
+09:11 < horms> that is fine
+09:11 < horms> i usually report on that too :)
+09:11 < horms> the bsp team know we don't just automatically take their work into upstream
+09:13 < wsa_> :)
+09:13 < wsa_> other than that, any updates from your side regarding the IO group todo list?
+09:13 < horms> kaneko san and i have made a bit of progress on etheravb, which is what i usually report on here
+09:14 < horms> but that is included in the todo lists i posted
+09:14 < horms> sergei also got all excited about not maintaining ether avb
+09:14 < horms> he is s funny fellow
+09:14 < horms> not much else on my side
+09:15 < wsa_> OK
+09:15 < wsa_> geert?
+09:15 < geertu> SCIF BRG is public
+09:15 < geertu> I have to do some rework and add support for more SoCs
+09:16 < geertu> (in progress)
+09:16 < geertu> Has anyone else tried this?
+09:16 < geertu> I'm seeing some mangled data on the serial console when both the kernel and userspace output at the same time
+09:16 < geertu> Have to investigate what's the reason for that
+09:17 < wsa_> sorry, haven't tried it
+09:17 < geertu> About MSIOF
+09:18 < geertu> There are indeed issues with it on Gen3. The BSP claims to have solutions for some, still have to try them
+09:19 < geertu> The BSP commit messages are a bit confusing.
+09:19 < wsa_> is this a seperate AI fo us?
+09:19 < wsa_> Yes, they are :)
+09:19 < wsa_> sometomes
+09:19 < wsa_> sometimes
+09:19 < geertu> Also the report from Tokyo we got about MSIOF working for RX, but not for TX
+09:19 < geertu> Perhaps it becomes clearer after trying the patches from BSP
+09:20 < geertu> I do think we need an entry in to TODO list for MSIOF on Gen3
+09:20 < geertu> s/to/the/
+09:21 < wsa_> +MSIOF,v4.5,plan,geert,Investigate issues on Gen3
+09:21 < wsa_> ?
+09:21 < geertu> ok
+09:21 < wsa_> What about:
+09:21 < wsa_> SCIF,?,noplan,?,FIFO drain issue
+09:21 < wsa_> is this really noplan?
+09:22 < geertu> No, Magnus asked to look into it after New Year
+09:22 < geertu> s/asked/asked me/
+09:22 < wsa_> and is the description descriptive enough?
+09:22 < geertu> It's about bytes stuck in the FIFO and/or serial layer
+09:22 < geertu> Should the input FIFO be flushed on device open
+09:22 < geertu> ?
+09:23 < wsa_> ok
+09:23 < geertu> Perhaps someone around here just knows ;-)
+09:23 < wsa_> I'd go for asking Alan Cox
+09:23 < geertu> Currently if you run data transfer integrity tests between serial ports, the test may fail because there's still data in the input FIFO (or tty subsystem, don't know for sure) from previous use
+09:24 < wsa_> he used to know details from "the old days" when I had a question about the TTY layer :)
+09:24 < wsa_> btw simon:
+09:24 < wsa_> gpio-rcar,v4.5,merged,kaneko,Upstream BSP v3.0.3 patch: sata_rcar: Add compatible string for r8a7795
+09:25 < wsa_> the above line looks strange to me because of the combination of gpio-rcar and SATA
+09:26 < geertu> s/gpio-rcar/sata_rcar/
+09:26 < wsa_> that would make sense to me, yes
+09:27 < geertu> renesas,gpio-r8a7795 is upstream
+09:27 < horms> i think its a typo as geert suggests
+09:27 < horms> i'll fix it if its on one of my lists
+09:27 < wsa_> your upport list
+09:27 < horms> ok, will fix
+09:28 < horms> about usb3.0. it is present on lager but not porter (or any other gen2 board i think)
+09:28 < horms> perhaps adding support to lager is a job for the i/o team. or perhaps nothing is needed?
+09:29 < horms> there seems to be something relevant in the v1.9.6 BSP, so I guess it could be upported
+09:29 < wsa_> not sure; I just noted the blue USB connector on my Lager and wondered if it could be easily integrated if integration was done for Koelsch already
+09:30 < horms> &xhci {
+09:30 < horms>         status = "okay";
+09:30 < horms> };
+09:30 < horms> maybe :^)
+09:30 < wsa_> the integration list was so huge, I thought another item wouldn't hurt ;)))
+09:30 < horms> ok, i am bind
+09:30 < horms> i see it for laer now
+09:30 < horms> lager now
+09:31 < horms> but i don't think its wired up for koelsch
+09:31 < horms> sore
+09:31 < horms> sure the more items the merrier!
+09:31 < wsa_> ok, next steps:
+09:32 < wsa_> buisness as usual, I'd assume
+09:32 < wsa_> simon does EtherAVB
+09:32 < wsa_> wolfram does planned I2C items scheduled for 4.5
+09:32 < wsa_> geert continues hacking BRG and MSIOF?
+09:33 < geertu> yes
+09:33 < geertu> There's also (H)SCIF DMA on Gen3
+09:33 < geertu> There's (sort of) a task for that in Core
+09:34 < wsa_> ok
+09:34 < geertu> Doesn't hurt to have a task for that in IO
+09:35 < wsa_> SCIF,v4.5,plan,geert,DMA support for Gen3
+09:35 < wsa_> ?
+09:36 < horms> if it is compatible with gen2 you can ship it off to integration/upporting. but if its a priority you may want to keep it
+09:36 < geertu> Last time I tried, TX DMA works, RX doesn't
+09:37 < horms> ok
+09:37 < geertu> Magnus claims RX works for him with IPMMU, but he has different firmware
+09:37 < horms> sounds like you need to keep that one for yourself then
+09:37 < geertu> Yep ;_)
+09:39 < wsa_> i think we are done, or?
+09:39 < geertu> I think so
+09:41 < wsa_> ok, then
+09:41 < wsa_> thanks for your input!
+09:42 < wsa_> i think it makes sense to have one more meeting this year
+09:42 < wsa_> a short one like today
+09:42 < wsa_> i'll suggest something in the report mail
+09:42 < geertu> ok
+09:43 < wsa_> so, have a great day!
+09:43 < horms> likewise
+09:43 < geertu> bye!
+09:43 < horms> bye
+--- Log closed Mon Dec 07 09:43:58 2015