summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20170803-mm-chatlog
diff options
context:
space:
mode:
authorKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2019-12-23 14:27:52 +0900
committerKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2019-12-23 14:27:52 +0900
commitdc71f3518c95f8d9d306e8a4e53bc9bd2e9928e3 (patch)
tree54552f6ba6cec40e16cef5c22043d9f510087e00 /wiki/Chat_log/20170803-mm-chatlog
parentbb506a3f4c5441ecb212874077ad8b1bf335c936 (diff)
parent05040a728026b28ce7c6183d2adfa80218b306cb (diff)
Merge remote-tracking branch 'gitlab/wiki' into HEAD
Diffstat (limited to 'wiki/Chat_log/20170803-mm-chatlog')
-rw-r--r--wiki/Chat_log/20170803-mm-chatlog243
1 files changed, 243 insertions, 0 deletions
diff --git a/wiki/Chat_log/20170803-mm-chatlog b/wiki/Chat_log/20170803-mm-chatlog
new file mode 100644
index 0000000..9783fb9
--- /dev/null
+++ b/wiki/Chat_log/20170803-mm-chatlog
@@ -0,0 +1,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