summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20180509-io-chatlog
blob: 675203770f7987b9e1235b248af2e9c90bfcf288 (plain)
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
132
133
134
135
136
137
138
139
140
141
142
143
144
09:03 < wsa_> welcome to this io meeting
09:03 -!- morimoto [~user@relprex3.renesas.com] has joined #periperi
09:03 < wsa_> agenda will be status updates and open questions
09:04 < wsa_> here are my collected status updates:
09:04 < wsa_> A - what have I done since last time
09:04 < wsa_> ------------------------------------
09:04 < wsa_> Geert
09:04 < wsa_> : updated the Gen2 watchdog blacklist
09:04 < wsa_> Kaneko-san
09:04 < wsa_> : posted series for M3-N SDHI support
09:04 < wsa_> Niklas
09:04 < wsa_> : got most thermal patches merged, did M3-N I2C enablement
09:04 < wsa_> Shimoda-san
09:04 < wsa_> : got upstream feedback about USB role switch, debugged suspend/resume issue
09:04 < wsa_> Simon
09:04 < wsa_> : sent out some DTS and defconfig patches
09:04 < wsa_> Ulrich
09:04 < wsa_> : checked BSP patch about RPM with SCIF
09:04 < wsa_> Wolfram
09:04 < wsa_> : started upstream discussions about I2C core PM and MMC/SD fallback for highspeed modes,
09:04 < wsa_>   sent out patches for I2C PM & M3-N WDT & EEPROMs on Gen3 + Alt & documentation for i2c-rcar,
09:04 < wsa_>   analyzed and reported back a breakage of a BSP patch for i2c-rcar, discussed periject, tested
09:04 < wsa_>   M3-N SDHI, and sent out two tree-wide cleanup series
09:04 < wsa_> B - what I want to do until next time
09:04 < wsa_> -------------------------------------
09:04 < wsa_> Kaneko-san
09:04 < wsa_> : wants to send next version of D3 thermal series and M3-N SDHI support
09:04 < wsa_> Niklas
09:04 < wsa_> : wants to resume SDHI upporting work
09:04 < wsa_> Shimoda-san
09:04 < wsa_> : wants to keep at the USB role switch topic, continue with the suspend/resume issue, and implement
09:04 < wsa_>   PHY GPIO support for E3 as well as Ethernet support for E3
09:04 < wsa_> Simon
09:04 < wsa_> : wants to continue HS400 support, follow up on RAVB upporting, and update QEMU performance testing report
09:04 < wsa_> Ulrich
09:04 < wsa_> : wants to ask BSP team about the SCIF patch
09:04 < wsa_> Wolfram
09:04 < wsa_> : wants to keep up with the started discussions, do more BSP upporting, implement QEMU VIRTIO
09:04 < wsa_>   passthrough for I2C clients
09:04 < wsa_> C - problems I currently have
09:04 < wsa_> -----------------------------
09:04 < wsa_> Niklas:
09:04 < wsa_> : lagged with SDHI work because of other stuff, still needs HW for Gen3 thermal fuses 
09:04 < wsa_> Ulrich:
09:04 < wsa_> : needs decision how to handle DMA for SCIF2 on Gen3
09:04 < wsa_> Wolfram
09:04 < wsa_> : couldn't find a non-VIRTIO solution for QEMU I2C passthrough because of the a-priori-knowledge problem
09:04 < wsa_> Please let me know if I missed / misinterpreted something
09:05 < wsa_> About I2C on M3-N, it seems we need conflict management here ;)
09:06 < wsa_> Niklas did it already because he needed it for MM work, but it was scheduled for Kaneko-san
09:06 < wsa_> However, there seems to be more testing missing
09:06 < geertu> wsa_: Same for M3-N WDT?
09:07 < neg> I'm happy to drop my patches as long as M3-N I2C4 are in next renesas-drivers ;-)
09:07 < wsa_> horms: did Kaneko-san already starte with I2C on M3-N?
09:07 < horms> wsa_: I asked him to but I doubt he has
09:08 < horms> likewise for WDT
09:08 < horms> the usual pattern is that I ping him after these meetings and magically patches appear
09:09 < horms> So how about I ask Kaneko-san to handle WDT and drop I2C?
09:09 < wsa_> so, maybe Niklas can post the patches as RFT and Kaneko-san can review/test them? Do you think this would work?
09:09 < geertu> Testing patches is always a good thing to do...
09:11 < horms> wsa_: well, the testing-arm of the Kaneko-san operation is me. but yes, that sounds like a good plan
09:11 < wsa_> about WDT: I only sent out the bindings, but didn't update the DTS etc...
09:11 < wsa_> or did someone do this and I missed it?
09:12 < wsa_> neg: can you post the patch as RFT then?
09:12 < horms> WDT: How about I check and task Kaneko-san with doing whatever is missing
09:12 < neg> wsa_: will do
09:12 < wsa_> horms: perfect
09:13 < wsa_> about the SCIF2 DMA issue
09:13 < wsa_> that came up before, no?
09:13 < wsa_> I think we know it is there but it is not official
09:14 < geertu> I've justed checked rev 1.00
09:14 < geertu> SCIF2 exists in the SCIF section
09:14 < uli___> so it officially exists now?
09:14 < geertu> SCIF2 interrupt is now documented as SCIF2 (I think it wasn't in some older rev)
09:14 < geertu> SCIF2 module clock is now documented as SCIF2 (I think it wasn't in some older rev)
09:15 < geertu> SCIF2 DMA is not documented.
09:15 < geertu> Note that the interrupt, module clock, and DMA channel numbers are "odd", and may related to another undocumented module (irda?)
09:16 < wsa_> but it does work as a SCIF?
09:16 < geertu> IIRC, in the first rev SCIF2 didn't exist at all, but it obviously works, as it's the consle
09:16 < geertu> s/consle/console/
09:16 < wsa_> that answers :)
09:17 < wsa_> well, let's stick to the documentation I'd say
09:17 < geertu> And DMA works, too. It doesn't work when you use the "expected" (check the holes in the datasheet) DMA channel numbers
09:17 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi
09:17 -!- horms_ [~horms@a80-127-179-77.adsl.xs4all.nl] has joined #periperi
09:18 -!- horms [~horms@2001:982:756:1:c685:8ff:fe7c:9971] has quit Quit: Leaving
09:18 -!- horms_ is now known as horms
09:18 < wsa_> uli___: so, I'd think no DMA for SCIF2 as of nwo
09:18 < wsa_> now
09:18 < geertu> Note: With "exist" I mean "documented"
09:19 < geertu> We have it enabled, and it works?
09:19 < geertu> on H3
09:19 < geertu> not yet on M3-W (but I have it enabled in my local tree since the beginning)
09:20 < uli___> it's enabled on d3 as well, iirc
09:20 < geertu> Yep, D3 too
09:20 < wsa_> I currently get a number of requests from Renesas to make the drivers work like the documentation says
09:20 < wsa_> although they work as is
09:21 < wsa_> and having witnessed some safety workshops recently I know there are people taking care of using only documented things :)
09:22 < wsa_> we can ask why this is not documented
09:22 < horms> So the idea is to implement the driver as per the documentation. Does this usually not change the observed behaviour of the driver?
09:22 < wsa_> it sometimes does
09:23 < wsa_> I will have this discussion with the BSP team about the patch breaking REP_START on I2C
09:23 < wsa_> It will be interesting
09:23 < wsa_> I assume there can be exceptions to the rule
09:24 < wsa_> but not mentioning DMA channels is trivial, or?
09:25 < wsa_> or even better:
09:25 < wsa_> ask the HW team if we can use it in upstream kernels
09:26 < wsa_> and if so, add a comment where we got this add. information
09:27 < wsa_> uli___: can you do that?
09:27 < geertu> I think it was documented as the irda DMA channel in early datasheets
09:27 < uli___> so we leave the dmas in, but document that they are undocumented?
09:27 < wsa_> we ask the HW team if we can use these DMA channels in upstream which "work for us"
09:28 < uli___> ah, ok
09:28 < wsa_> although undocumented
09:28 < wsa_> and let's see what they say
09:28 < uli___> yes, i can do that
09:28 < wsa_> thx
09:29 < wsa_> short about SDHI
09:30 < wsa_> horms: about the core changes, I was hoping for Ulf to comment
09:30 < wsa_> I can have another look but I am not sure I can add much
09:30 < wsa_> I'd like to know Ulf's opinion because he knows way more MMC hardware
09:30 < horms> Ok, maybe I can ping him
09:31 < horms> I understand he wants us to use hooks
09:31 < wsa_> yes, please try
09:31 < horms> But as you can see from the patch I found the existing hooks inadequate
09:31 < horms> And then found myself guessing how he would like new hooks to look
09:31 < horms> Ok, will do
09:32 < wsa_> in general, what neg said is true for SDHI in general: it is a bit lagging; for me, too, since I did majorly I2C the last period
09:32 < horms> I think we can upstream M3-N (non HS400) SDHI support sooner than later, do you agree?
09:32 < wsa_> horms: certainly
09:33 < wsa_> so maybe we all can give it some more love in the next period (me included)
09:34 < horms> agreed
09:34 < wsa_> so, one more little wish: if you are on holidays, please mark it in the B) section of your report
09:34 < horms> by next period do you mean between now and the next meeting?
09:34 < wsa_> then i know better where to find it
09:34 < wsa_> horms: yes
09:35 < wsa_> for now ;)
09:35 < wsa_> it will need more love in general
09:35 < wsa_> this was it from my side, any topics from your side?
09:36 < wsa_> nope
09:36 < wsa_> geertu: then, I'll hand over to you
09:36 < wsa_> Thanks for this meeting!
09:37 < geertu> wsa_: Thanks!
09:37 < wsa_> enjoy the rest of the day