1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
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
|
