summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20170803-mm-chatlog
blob: 9783fb9820ffe18fd3f7cc15c09d029a2235d1db (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
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
Multimedia-chat-meeting-2017-08-03

10:28 < pinchartl> Jacopo is on vacation, Kieran and Morimoto-san have reported by e-mail and are excused
10:28 < wsa_> thanks, will have :D
10:28 < pinchartl> let's start with status update
10:29 < pinchartl> in inverse e-mail report order... *drum roll*
10:29 < pinchartl> uli___: welcome :-)
10:29 < uli___> do i at least get a prize?
10:29 < uli___> anyway...
10:29 < uli___> so i think one of the max9260 on the blanche board has actually died
10:29 < pinchartl> :-)
10:29 < uli___> not a problem for me, there are still 5 to go
10:29 < uli___> at least for now... :)
10:30 < pinchartl> do you know how it might have died ?
10:30 < uli___> no idea. but i strongly suspect that it's not a coincidence that it's the one the cable was attached to previously
10:30 < uli___> maybe the camera board does shady stuff
10:30 < uli___> but there's no way to tell, really
10:31 < pinchartl> does the IC get hotter than the other ones ?
10:31 < uli___> dammsan: please feel the chip for us :)
10:32 < pinchartl> not much we can do at this point I suppose
10:32 < pinchartl> but it would be interesting to log your actions to have data in case another one dies
10:32 < uli___> that might be a good idea
10:33 < uli___> so far, i have only read the id register on the max9259
10:33 < pinchartl> is power to the MAX9260 controllable by Linux ?
10:34 < uli___> partially, i think. there are sleep modes; i would have to check the datasheet
10:34 < pinchartl> you might want to check power sequences, the chip might not appreciate having the camera powered if it isn't itself
10:35 < uli___> by default, all chips are up
10:35 < uli___> maybe the camera board stabilizes earlier than the blanche board?
10:35 < pinchartl> I have no idea
10:36 < uli___> there might have to be a power-up delay for safe operation
10:37 < uli___> anyway, apart from that i'm mentally preparing myself for a week of sd card swapping
10:37 < pinchartl> :-)
10:38 < uli___> in order to find out where the chromebook fails to boot
10:38 < uli___> that's it from me
10:38 < pinchartl> thank you
10:38 < pinchartl> next, Kieran, who reported by e-mail
10:38 < pinchartl> since last meeting:
10:39 < pinchartl> - Submitted 8 channel camera patches with Laurent.
10:39 < pinchartl> - Holiday
10:39 < pinchartl> - Reviewed Laurent's VSP-Du series'
10:39 < pinchartl> for the next two weeks:
10:39 < pinchartl> - Complete my dl-caching task
10:39 < pinchartl> - Finish reviewing Laurent's patches.
10:39 < pinchartl> Issues and blockers: None
10:39 < pinchartl> next, still through e-mail, Morimoto-san
10:40 < pinchartl> since last meeting:
10:40 < pinchartl> - More ALSA framework code cleanups, posted to mailing list and under review
10:40 < pinchartl> for the next two weeks:
10:40 < pinchartl> - Continue with code cleanup
10:40 < pinchartl> Issues and blockers: None
10:40 < pinchartl> next, Niklas
10:40 < neg> (IRC version, please use email for report)
10:40 < neg> A)
10:40 < neg>     - [RFC 0/5] arm64: dts: renesas: add VIN, CSI-2 and ADV7482 nodes
10:40 < neg>     - [PATCH 0/4] v4l: async: fixes for v4l2_async_notifier_unregister()
10:40 < neg>     - Documented VIN findings on Salvator-XS, and fixed issue in CSI-2
10:40 < neg>       driver which effected CVBS capture on H3 ES2.0.
10:40 < neg>     - Picked up minor tweaks to the CSI-2 driver from BSP code.
10:40 < neg>     - Assembled and tested the 8-ch camera board, managed to capture from
10:40 < neg>       one camera using one camera.
10:41 < neg>     - Had planing meeting with Laurent and sent out plan and status
10:41 < neg>       about Multiple Virtual Channels Development in collaboration with
10:41 < neg>       Laurent and Kieran.
10:41 < neg> B)
10:41 < neg>     - Finish a (somewhat) working prototype of Multiple Virtual
10:41 < neg>       Channels. Goal is to do this using the max9286 board with ADV7482
10:41 < neg>       backup.
10:41 < neg>     - Keep pushing updates for incremental async and R-Car CSI-2 driver
10:41 < neg>       and its dependencies.
10:41 < neg>     - Publish a new rcar-vin-elinux-v11 tag to elinux.
10:41 < neg> C)
10:41 < neg>     - Sakari is and Hans have been on vacation so stuff is pending
10:41 < neg>       awaiting there return :-)
10:41 < neg>     - All 8 cameras I recived fail to probe at the same time, but I can
10:41 < neg>       get all to probe "sometime". I'm investigating this but if others
10:41 < neg>       know more please let me know.
10:41 < neg>     - The suspicion that the MAX9286 can't output using different VC makes
10:41 < neg>       me wonder if I should continue with the Multiple Virtual Channels plan?
10:41 < neg> Other)
10:41 < neg> - I will be on a short vacation to Rome 13/8 -- 17/8
10:41 < neg> --EOT--
10:42 < pinchartl> you managed to capture from one camera using one camera. well, that's kind of expected, I would have been surprised if you had captured from one camera using, let's say, a fridge :-)
10:42 < dammsan> roman holiday!
10:42 < neg> pinchartl: embrace the IoT
10:42 < pinchartl> could you please update https://osdr.renesas.com/projects/linux-kernel-development/wiki/Member_info with your holidays information ?
10:42 < neg> pinchartl: sure will update the wiki, thanks for reminindg me
10:43 < pinchartl> uli___: while at it, you're the only one without your public ssh key listed in https://osdr.renesas.com/projects/linux-kernel-development/wiki/Member_info
10:44 < pinchartl> neg: thank you
10:44 < pinchartl> next, Magnus
10:44 < pinchartl> dammsan: anything to report ?
10:44 < dammsan> nope
10:44 < dammsan> poking with v3m at the moment
10:44 < uli___> pinchartl: i'll rectify that then.
10:45 < pinchartl> uli___: thanks
10:45 < pinchartl> dammsan: ok
10:46 < pinchartl> next, me
10:46 -!- Irssi: Pasting 16 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
10:46 < pinchartl> Since last meeting:
10:46 < pinchartl> - More max9286 + rdacm20 cleanups
10:46 < pinchartl> - Discussed CSI-2 virtual channel support with Niklas
10:46 < pinchartl> - Fixed the DU + IPMMU issue (hopefully) for good
10:46 < pinchartl> - Rebased (and resubmitted some of the) pending DU patches
10:46 < pinchartl> For the next two weeks:
10:46 < pinchartl> - Extend the DU test suite
10:46 < pinchartl> - CSI-2 virtual channel support
10:46 < pinchartl> Issues and Blockers:
10:46 < pinchartl> - The MAX9286 requires sources to be synchronized. This will likely require V4L2 API extensions.
10:46 < pinchartl> - It isn't clear how the MAX9286 combines input frames. Multiple modes are supported, but the datasheet doesn't document how to select them. Support from Maxim might be needed.
10:47 < pinchartl> that's it for status reports
10:47 < pinchartl> any question so far ?
10:48 < neg> Should I push on with the Multiple Virtual Channels plan as we discussed even with the new suspicions of the MAX9286 and VC ?
10:48 < pinchartl> please do
10:48 < pinchartl> it's needed anyway
10:48 < pinchartl> I'll try to get more information
10:49 < neg> OK
10:50 < pinchartl> I will check with Morimoto-san if we can have support from Maxim
10:51 < pinchartl> what bothers me is that I recall getting information about I2C address programmation in the MAX9286 and MAX9271, from Maxim I believe, but I can't find the e-mail
10:51 < pinchartl> maybe it was a dream :-)
10:51 < pinchartl> next topic, questions from the BSP team
10:52 < pinchartl> Morimoto-san enquired in his e-mail about the status of
10:52 < pinchartl> - DU / VSP initial sequence
10:52 < pinchartl> - DU vblank handling
10:52 < pinchartl> - VIN V4L2_FIELD_SEQ_TB/TB
10:52 < pinchartl> the first two are done, patches have been posted, and I'm waiting for Kieran to review the last two patches before sending a pull request
10:53 < pinchartl> Niklas, the latter has been posted but depends on upstreaming Gen3 support for VIN as far as I understand, right ?
10:53 < neg> VIN V4L2_FIELD_SEQ_TB/TB is also done and patches posted, there is room for future improvment by makeing it possible to use the continues capture mode, but AFIU there is no request for this at the moment
10:54 < neg> Yes they depend on the Gen3 patches, but att support to both Gen2 and Gen3
10:54 < neg> s/att/add/
10:56 < pinchartl> thank you
10:56 < pinchartl> the next question comes from me and is for Magnus and Morimoto-san
10:56 < dammsan> shoot
10:57 < pinchartl> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Salvator-X_MAXIM_camera_board describes a "8ch Camera WorkAround"
10:57 < pinchartl> with the "Power ON order (with 8ch WorkAround if needed)"
10:57 < pinchartl> the workaround relates to powering one set of 4 cameras first, and the other after a delay
10:58 < pinchartl> this isn't needed anymore with the latest code
10:58 < pinchartl> so we don't bother
10:58 < pinchartl> however, we still power the MAX9286 one second later than the Salvator-X
10:58 < pinchartl> the wiki page doesn't explain why that is needed
10:58 < pinchartl> I'd like to understand the reason behind that delay to check whether it's still needed
10:59 < dammsan> i don't know why to be honest. feel free to ask morimoto-san via email =)
10:59 < dammsan> i suspect it is related to some issue with reset
11:00 < pinchartl> OK, I will ask Morimoto-san then
11:00 < pinchartl> thank you
11:00 < dammsan> thanks
11:01 < pinchartl> then, Magnus, two items for you
11:01 < pinchartl> one, an official ping about video codecs
11:01 < dammsan> go ahead
11:01 < pinchartl> you asked me to ping you to get more information about a possible future plan
11:01 < pinchartl> so here you are :-)
11:02 < dammsan> thanks =)
11:02 < dammsan> noted
11:02 < pinchartl> thank you
11:02 < pinchartl> then, you mentioned that you'd like to start discussing additional tasks for Q3/2
11:02 < pinchartl> I don't know if that was for multimedia only or for all groups
11:02 < pinchartl> but the stage is yours
11:02 < dammsan> all groups really
11:03 < dammsan> i have no special requirements at this point
11:03 < dammsan> just noticed that some people still have unassigned slots
11:03 < pinchartl> for Q3/2 ?
11:03 < dammsan> yeah
11:04 < dammsan> so if you want to make use of your slots then i suggest that each guy and/or the group leaders suggest some activities =)
11:05 < pinchartl> is there any request you're aware of from Renesas ?
11:05 < pinchartl> or from you ? :-)
11:06 < dammsan> for m/m i care about consistent support level in mainline
11:06 < pinchartl> what do you mean by that ?
11:06 < dammsan> so perhaps salvator-x and xs and ulcbs may be in not-so-onsistent state
11:06 < dammsan> i mean that if we for instance enabled MMC on one board we should do it on other boards as well
11:06 < dammsan> not sure what the state is for m/m
11:07 < dammsan> with video out and video-in
11:07 < pinchartl> yes, I agree
11:07 < pinchartl> should we start buying ULCBs ?
11:08 < dammsan> i think that makes sense yes
11:08 < dammsan> you are free to use my boards via remote access too
11:08 < pinchartl> for display it's better to have local access
11:08 < pinchartl> can hardware costs for ULCBs be charged to Jinso ?
11:09 < dammsan> i got some converters so i should be able to use HDMI-out via the Adder IPEPS VNC magic too
11:09 < dammsan> i think it should be doable, but may i propose that we associate the cost with additional tasks?
11:09 < pinchartl> sure
11:09 < dammsan> if you can figure out what is missing then we can make sure to provide funding for the required h/w
11:10 < pinchartl> I suppose we should target both the H3SK and M3SK ?
11:10 < dammsan> also the never-ending vin-for-rcar-gen3 =)
11:10 < dammsan> i think so
11:10 < wsa_> dammsan: good news, SDHI/MMC enablement for D3/XS was planned for 9/M together with the drive_strength task
11:10 < dammsan> just make sure to get an H3 with ES2.
11:11 < dammsan> wsa_: good!!
11:12 < dammsan> then we have D3 and V3M as well, but those need to wait a bit i think
11:12 < pinchartl> thank you
11:12 < dammsan> thanks
11:13 < pinchartl> regarding additional tasks, if anyone has one (or more) specific task he wants to work on, please let me know
11:13 < wsa_> ditto
11:15 < pinchartl> (buying the H3SK might not be that easy)
11:15 < dammsan> you can begin with M3 perhaps
11:15 < pinchartl> no stock at digikey, avnet europe doesn't even list it on their website
11:15 < pinchartl> same for M3SK :-)
11:15 < dammsan> i've got both H3 ES1 and ES2 boards
11:16 < dammsan> if anyone wants to go down the route of remote access
11:16 < pinchartl> where did you buy them ?
11:16 < dammsan> i received them
11:16 < dammsan> and modified them to get the automatic power-on thing going
11:16 < pinchartl> (out of stock at future electronics as well)
11:17 < dammsan> friggin-push-button-power-on
11:17 < pinchartl> sounds like we'll have to postpone that
11:17 < pinchartl> or ask Renesas to ship them
11:17 < dammsan> that does not seem to be the preferred way
11:17 < dammsan> but feel free to ask morimoto-san =)
11:19 < pinchartl> well, if it's out of stock everywhere, and Renesas doesn't want to ship boards, then there's nothing we can do
11:19 < pinchartl> I'll ask Morimoto-san
11:19 < dammsan> thanks!
11:20 < dammsan> i can hook up hdmi cables for loopback testing
11:20 < dammsan> or use the adder ipeps
11:20 < dammsan> its just integration, right?
11:20 < dammsan> it should be fairly straight forward i believe
11:20 < pinchartl> it's just integration until we run into issues :-)
11:21 < dammsan> true
11:22 < pinchartl> and I'll assume we'll need ULCBs for Kingfisher development too
11:22 < pinchartl> so it makes sense to plan for that
11:23 < pinchartl> does Kingfisher support both H3SK and M3SK ?
11:24 < dammsan> for multi-camera development v3m might be less error-prone
11:24 < dammsan> not sure, it seems to have some hardware issues at the moment
11:25 < pinchartl> is there a V3M ULCB ?
11:25 < dammsan> not that i'm aware of
11:25 < dammsan> V3M seems to include max9286
11:25 < pinchartl> ok
11:26 < pinchartl> what's the name of the board ?
11:26 < dammsan> eagle i think
11:26 < dammsan> quad gsml unless i'm mistaken
11:27 < pinchartl> https://github.com/CogentEmbedded/meta-rcar/commit/9e5839a0a7930e0677ff52ac116c81dbc6313b6e
11:27 < pinchartl> seems so
11:27 < pinchartl> and again, it seems that Cogent gets boards before we do
11:28 < dammsan> isn't it great? =\
11:28 < dammsan> i had to struggle quite a bit to get the v3m
11:29 < pinchartl> I'll ask about that in the meeting report
11:29 < dammsan> good idea
11:29 < dammsan> thanks!
11:30 < pinchartl> you're welcome
11:30 < pinchartl> that's it for me
11:30 < pinchartl> any other discussion topic from anyone ?
11:31 < neg> Not from me
11:31 < pinchartl> the next meeting will take place two weeks from now on the 17th of August
11:31 < pinchartl> I propose adjourning this meeting. does anyone second ?
11:32 < dammsan> yep
11:32 < neg> seconded
11:32 < pinchartl> meeting adjourned, thank you for attending