summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20151030-io-chatlog
blob: 8d8a24a7a7e34cc9d09ea0e2b3d34d8de552fd68 (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
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
--- Log opened Fri Oct 30 09:45:18 2015
09:45 -!- wsa_ [~wsa@p4FE255A0.dip0.t-ipconnect.de] has joined #periperi
09:45 -!- Irssi: #periperi: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
09:45 -!- Irssi: Join to #periperi was synced in 0 secs
09:45 < wsa_> hi there
09:45 < geertu> Hi Wolfram
09:46 < wsa_> hi geert
09:51 < wsa_> shall we maybe meet somewhere else (#periperi-io) so other people can stay here?
09:54 < geertu> Fine for me
09:55 < wsa_> done
09:55 < wsa_> I can't reproduce any of the issues pinchartl is seeing on Magnus' Koelsch :(
09:56 < wsa_> using his config and renesas-drivers-2015-10-27-v4.3-rc7
09:56 < geertu> Laurent and I both a version with a U-Boot that keeps MSTP clocks running
09:57 < geertu> I do see i2c failures with recent kernels since I enabled DU and friends
09:57 < wsa_> i should be able to emulate that with some 'mw' magic, or?
09:57 < geertu> I do run patches that disable MSTP clocks early in boot
09:57 < geertu> I'll email them to you
09:58 < wsa_> disable?
09:58 < wsa_> i thought your version keeps them running?
09:58 < geertu> yeah, I'm a bit puzzled, as I'd expect _you_ to see failures, not Laurent/
09:59 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi
09:59 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi
09:59 < geertu> Ah, the "real cold boot" of Koelsch now fails every day with an interrupt storm due to i2c not working for the regulator quirk
09:59 < wsa_> hmm, i think i'd prefer your uboot binary so can load it second stage to RAM
10:00 < wsa_> hello shimoda-san, morimoto-san
10:00 < shimoda> hello wolfram-san!
10:00 < wsa_> please join #periperi-io for the meeting
10:00 < shimoda> i got it
10:01 < wsa_> geertu: my best guess so far is that because of running clocks (and some weird leftover states from the bootloader) the IP core is an unknown state and not properly reinitialized yet
10:03 < geertu> Morimoto-san's "[PATCH] i2c: rcar: call rcar_i2c_init() after pm_runtime_get_sync()" doesn't fix the regylator interrupt storm at boot :-(
10:04 < geertu> If I keep he kernel running until the IRQ subsystem kills the interrupt, usually next reboot works
10:04 < wsa_> geertu: is that with koelsch, too?
10:04 < geertu> yep
10:04 < wsa_> please send me your .config
10:04 < wsa_> and now for the meeting
10:05 < geertu> It started earlier this week
10:05 < wsa_> :)
10:05 < geertu> Issue only happens if I power the board off for a long enough period (i.e. usually at night)
10:06 < geertu> OK, boot completed
10:06 < geertu> resetting
10:06 < geertu> and still working...
10:08 < wsa_> WTF?
10:48 < geertu> BTW, I will most probably have a day off on Wed and Thu
--- Log closed Fri Oct 30 10:52:49 2015
--- Log opened Fri Oct 30 09:54:50 2015
09:54 -!- wsa_ [~wsa@p4FE255A0.dip0.t-ipconnect.de] has joined #periperi-io
09:54 -!- ServerMode/#periperi-io [+ns] by hitchcock.freenode.net
09:54 -!- Irssi: #periperi-io: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
09:54 -!- Irssi: Join to #periperi-io was synced in 0 secs
09:55 -!- geertu [~geert@d54C36A7B.access.telenet.be] has joined #periperi-io
10:01 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi-io
10:01 < morimoto> Hi
10:01 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi-io
10:02 <@wsa_> hello
10:02 < shimoda> hello!
10:02 <@wsa_> let's wait one more minute for simon
10:03 <@wsa_> if he doesn't show up, we'll put this topic last
10:05 <@wsa_> so
10:05 <@wsa_> let's get this done fast and concentrated :)
10:05 < shimoda> :)
10:05 -!- horms [~horms@penelope-musen.kanocho.kobe.vergenet.net] has joined #periperi-io
10:06 <@wsa_> SDHI DMA: is the BSP team happy with the suggested workflow?
10:06 <@wsa_> hi simon, just in time
10:06 < horms> Apologies for not being more punctual
10:06 < shimoda> i make some patches of SDHI DMA for BSP team :)
10:07 < shimoda> so this patch set will release in early next month as renesas-bsp
10:07 < shimoda> .git
10:07 <@wsa_> great!
10:07 <@wsa_> then we can have a look about further refactoring
10:08 <@wsa_> how did PTP come along?
10:08 < shimoda> yes, I think we have to refactor the tmio driver somehow :)
10:09 < horms> wsa_: regarding ptp
10:09 < horms> I have looked over the bsp after learning it contains the required functionality
10:09 <@wsa_> shimoda: (yes, i think so, too. but let's talk over the code when it is available in git)
10:10 < horms> it seems to me that the only relevant code that is not upstream is to correct an assubmption that the input clock is running at 130MHz: as was the case on Gen2.
10:11 < horms> On the r8a7795 I believe the situation is that it should run at 133MHz, but due to the extal being 16.6Mhz rather than 33MHz it runs at half that speed. i.e. 66.6Mhz.
10:11 < shimoda> wsa_: agreed
10:11 < horms> I think the answer is to have the driver use the speed of its clock to set the register in question
10:11 < horms> i plan to see about implementing that
10:12 <@wsa_> okay, this sounds like a bit of work, but no major obstacle?
10:12 < horms> yes, i think so
10:12 <@wsa_> knock on wood :)
10:12 < horms> I think the main questin will be if the binding needs changing. to my mind the answer is "hopefully not"
10:13 < horms> in theory other clocks could be relevant
10:13 < horms> but in practice the hw only accepts using the high-speed peripheral clock (or what that was renamed to in gen3)
10:13 < horms> so fingers crossed it should not be too difficult to resolve in an upstreamable manner
10:14  * wsa_ crosses fingers
10:14 <@wsa_> thanks simon
10:14 <@wsa_> about PCIE
10:14 <@wsa_> I tested Phil's patches, and they turned out to go into the right directon, but being unusable for now
10:15 <@wsa_> even introducing a build error
10:15 < horms> :(
10:15 <@wsa_> Bjorn wants to drop the branch which would also be my favourite solution
10:16 < horms> thats fine by me. I'll be more careful with Phil's patches in future
10:16 <@wsa_> but i didn't want to suggest it directly because i wanted to be careful (from a diplomatic point of view)
10:16 < horms> do you need me to respond to the thread?
10:17 <@wsa_> if you want, but i don't think it is needed
10:17 < horms> ok
10:17 < horms> i prefer to take a back-seat with PCIe unless action is required
10:17 < horms> if the wheels fall off I'm happy to step in :)
10:18 <@wsa_> okay, thanks
10:18 <@wsa_> watchdog
10:18 < horms> from my pov phil should know what he is doing. its unfortunate if that isn't the case
10:18 < horms> but i will be more watchful
10:19 <@wsa_> make sure his patches get build tested
10:19 < horms> can do
10:19 <@wsa_> i also think that he knows what he is doing in general
10:19 <@wsa_> but this series wasn't his best one
10:19 <@wsa_> for whatever reason
10:19 < horms> ok
10:19 <@wsa_> watchdog ;)
10:20 <@wsa_> my current plan is to release the next version in the second week of November
10:20 <@wsa_> shimoda: will this be enough? or is it needed before that?
10:21 < shimoda> BSP point of view, they need next Wed. :)
10:22 < shimoda> however, they can use your current patch too
10:22 <@wsa_> i'll se what i can do
10:23 <@wsa_> how are the other deadlines?
10:23 < shimoda> thank you!
10:23 <@wsa_> did something urgent show up I missed so far?
10:24 < shimoda> about i/o group, no other deadlines, i think
10:25 <@wsa_> good
10:26 <@wsa_> so major topic seems to be i2c now :(
10:26 <@wsa_> i'll do some more debugging but if I can't reproduce the issues, I probably have to revert the latest r-car series
10:26 < shimoda> i think so ;)
10:27 < morimoto> About Laurent issue do you mean ?
10:27 <@wsa_> geert has some, too
10:27 <@wsa_> all on koelsch
10:28 < morimoto> OK
10:28 <@wsa_> but it doesn't show on Magnus Koelsch
10:28 <@wsa_> where i have remote access to
10:28 < morimoto> which ES number used ?
10:29 < morimoto> do you know ?
10:29 <@wsa_> I asked geert for his u-boot binary so I can start this second stage from RAM
10:29 < geertu> how do I get the U-Boot binary?
10:29 < geertu> raw QSPI contents
10:29 < geertu> ?
10:29 < geertu> Detected Renesas R-Car M2-W ES1.0
10:29 <@wsa_> I thought you have patches to u-boot?
10:29 <@wsa_> Laurent reported:
10:29 <@wsa_> RTPORC7791SEB00010S
10:29 <@wsa_> KOELSCH SN.057
10:30 < geertu> My Koelsch is SN.192, and Laurent's is older,so it should be ES1.0 too
10:30 < geertu> Mine ends with 11S
10:31 < geertu> Aha, different board revision too
10:31 <@wsa_> geertu: are those identification patches some way upstream?
10:31 < geertu> No, old version on periperi
10:31 < shimoda> about u-boot code of gen2: git://git.denx.de/u-boot-sh.git
10:31 < geertu> Can email out a new one, moved to drivers/soc and supporting H3 and M3-W
10:32 < shimoda> origin/renesas/bsp/rcar-gen2-7 branch is the latest
10:32 < geertu> yep, checkout b6af5fc
10:32 < geertu> Probably Wolfram (Magnus) has the latest version, in Dublin we saw it was from spring 2015
10:32 <@wsa_> geertu: new version sounds good
10:32 < geertu> So I have ver=U-Boot 2013.01.01-gb6af5fc (Nov 12 2013 - 14:33:51)
10:33 < geertu> wsa_: but you don't see the issue on new versions?
10:33 <@wsa_> nope
10:33 <@wsa_> morimoto: can we get a "changelog" for Koelsch board revisions?
10:33 <@wsa_> does something like this exist?
10:34 < morimoto> do you mean "board" changelog ?
10:34 <@wsa_> yes
10:34 < morimoto> let me check
10:35 <@wsa_> okay, i more and more get the impression i should revert the changes
10:35 < geertu> "[PATCH] [LOCAL] ARM: shmobile: Print SoC Product Version" sent to periperi
10:35 <@wsa_> they need more time (and not quick hacks) on some Koelsch boards
10:37 <@wsa_> please note that i am away next week
10:38 <@wsa_> i might be able to respond to emails
10:38 <@wsa_> i think we are done unless one of you has a topic left
10:39 < horms> none from my side
10:40 < morimoto> Can I interrupt ? The issue if for HDMI chip access ?
10:40 < morimoto> /if/is/
10:40 <@wsa_> yes
10:41 <@wsa_> adv7180
10:41 < morimoto> Thanks
10:41 < geertu> "Your message to periperi awaits moderator approval"
10:41 < horms> oh!
10:41 < geertu> geert+renesas is not a member ;-)
10:42 < horms> did you post just now?
10:42 < geertu> yes
10:42 < geertu> the patch I mentioned above
10:43 < horms> ok, i'll try and approve the post and whitelist your address
10:43 < geertu> thx!
10:44 <@wsa_> morimoto: can you email me your findings?
10:44 <@wsa_> they are much appreciated
10:45 <@wsa_> then, we could close this meeting
10:45 <@wsa_> and go for weekend :D (sooner or later, depending on TZ)
10:46 < shimoda> yes, thank you for the meeting!
10:46 < morimoto> Now, HW team is not here, I asked to them via email. please wait
10:46 <@wsa_> will do
10:46 <@wsa_> cya all!
10:47 < geertu> bye!
10:47 < morimoto> I will have day off on Mon, and Tue is Holiday in Japan.
10:47 < geertu> Have a nice weekend
10:47 < horms> enjoy
10:47 < morimoto> shimoda-san is OK in Mon, so please care it >> shimoda-san
10:47 < shimoda> have a nice weekend!
10:47 < morimoto> bye
--- Log closed Fri Oct 30 10:52:49 2015