summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20171123-mm-chatlog
diff options
context:
space:
mode:
authorKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2019-12-09 15:29:52 +0900
committerKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2019-12-09 16:23:07 +0900
commit55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce (patch)
tree6392fd201a51ff0f6dc0e474803e6f3b20919504 /wiki/Chat_log/20171123-mm-chatlog
parent5d9e1b983faf7645ddc3d45d28e612d2ac4179c0 (diff)
wiki: Porting wiki: Porting Chat Log
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Diffstat (limited to 'wiki/Chat_log/20171123-mm-chatlog')
-rw-r--r--wiki/Chat_log/20171123-mm-chatlog173
1 files changed, 173 insertions, 0 deletions
diff --git a/wiki/Chat_log/20171123-mm-chatlog b/wiki/Chat_log/20171123-mm-chatlog
new file mode 100644
index 0000000..3b34e7e
--- /dev/null
+++ b/wiki/Chat_log/20171123-mm-chatlog
@@ -0,0 +1,173 @@
+Multimedia-chat-meeting-2017-11-23
+
+08:59 < neg> morning
+09:00 < uli___> good morning
+09:00 <@pinchartl> huomenta
+09:00 <@pinchartl> it looks like there will be no core and I/O meeting today
+09:01 < kbingham[m]> Moaning :-)
+09:01 < kbingham[m]> (making tea then switching to laptop)
+09:02 <@pinchartl> the multimedia meeting was originally scheduled for 10:00 CET, but as there's no core or I/O portion, I suppose we can start right away
+09:02 <@pinchartl> although we might be missing jmondi ?
+09:03 < neg> pinchartl: hum just to clear that my new calender thinig handles timezoens ok, the invitation sent out was that for MM at 9 or 10?
+09:04 < jmondi> no no, I'm here!
+09:04 <@pinchartl> it was sent for 9:00 CET, adding to the confusion (or the lack of confusion, I don't know)
+09:04 <@pinchartl> jmondi: hello
+09:04 < jmondi> pinchartl: Hi there!
+09:05 <@pinchartl> let's start as soon as Kieran's tea is ready
+09:06 < kbingham[m]> Do start. I don't think I'm first :-)
+09:06 <@pinchartl> ok :-)
+09:06 <@pinchartl> so let's start with...
+09:06 <@pinchartl> uli___: your turn
+09:07 < uli___> ok
+09:07 < uli___> so i ported the chromeos gpu driver to mainline
+09:07 < uli___> and it sometimes works
+09:07 < uli___> usually it fails while waiting for the GPU firmware to boot
+09:07 < uli___> i think it's a power management issue
+09:08 < uli___> i'll give matthias brugger's new mmsys implementation a try
+09:08 < uli___> that might help because it manages the clocks
+09:08 <@pinchartl> when it doesn't fail to boot, does it render opengl correctly ?
+09:08 < uli___> yes
+09:08 < uli___> sometimes it freezes after a few frames, but usually it works
+09:09 < uli___> at any rate, this is not a problem that is likely to translate to gen3
+09:09 < uli___> so i'm not too worried about it for the next task
+09:09 < uli___> that's it for me
+09:10 <@pinchartl> ok
+09:10 <@pinchartl> I'm not sure I agree with that conclusion, but we'll see anyway :-)
+09:11 <@pinchartl> thank you
+09:11 < neg> uli___: your GPU work sounds interesting :-)
+09:11 <@pinchartl> next is...
+09:11 <@pinchartl> neg: your turn
+09:11 < neg> A)
+09:11 < neg> - [PATCH] v4l: async: use the v4l2_dev from the root notifier when matching sub-devices
+09:11 < neg> - [PATCH v11 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2
+09:11 < neg> - [PATCH v7 00/25] rcar-vin: Add Gen3 with media controller
+09:11 < neg> - Clarified last issue for VIN upstreming with Laurent and Hans
+09:12 < neg> - Begun rebasing multiple stream work on-top of Sakari's vc branch.
+09:12 < neg> B)
+09:12 < neg> - Once -rc1 is public post next versions of VIN and CSI-2 which I have hopes this is coming to an end :-)
+09:12 < neg> - Add V3M VIN routing table to VIN driver, and if nothing much else is missing on V3M test it.
+09:12 < neg> - Post new base of VIN and CSI-2 for vin/mux+gmsl. This will use the latest VIN and CSI-2 drivers but the first multiple stream prototype as before.
+09:12 < neg> - Continue the multiple stream work
+09:12 < neg> C)
+09:12 < neg> - None
+09:12 < neg> --EOT--
+09:13 <@pinchartl> thank you
+09:13 <@pinchartl> next is...
+09:13 <@pinchartl> kbingham[m]: is your tea ready ?
+09:13 < kbingham> pinchartl: Nice and hot yes :)
+09:14 < kbingham> So for me, since last meeting has been revisiting my pending patchsets, tlb and
+09:14 < kbingham> DL caching, and the support for suspend resume which didn't make it to mainline
+09:14 < kbingham> yet.
+09:14 < kbingham> From there - I've been mostly looking at V3M, and had a few stumbling points getting the board booting a default configuration.
+09:15 < kbingham> That's now resolved, and I've been working towards getting the dependencies for more useful systems to work.
+09:15 < kbingham> So I've now pulled in I2C and PFC support from Sergei's patches, (and Geert's integration branch) ... and started populating the DTB with more devices as specified on the data sheet.
+09:16 < neg> kbingham: thanks for making your V3M i2c branch public :-)
+09:16 < kbingham> Next, - I'll continue on the V3M for a bit - but I wonder if I should wait for Neg to look at the VIN routing ...
+09:16 < kbingham> Otherwise I'll keep ploughing through whatever seems useful.
+09:17 <@pinchartl> neg: when do you expect to post a patch for the VIN routing table ?
+09:17 < kbingham> I still ahve the VIN loopback tests to look at so I won't be blocked if I wait for neg to do his bit - and he'll be more effective at VIN routes than me :)
+09:18 < Marex> geertu: enjoyed what ?
+09:18 < kbingham> neg: No worries- I thought it owuld be useful to you - and was more work to get to that point than I would have liked. Didn't want you to have to repeat it
+09:18 < kbingham> So for me - VIN routes might be considered a blocker =- but other than that I seemingly have lots to do .
+09:18 < kbingham> EOT.
+09:19 <@pinchartl> kbingham: I think it makes sense to wait for Niklas, yes. you can move forward with I2C if you want up to the point where devices are detected, but for VIN support itself I'd leave it to Niklas
+09:19 < kbingham> pinchartl: Ack.
+09:19 < neg> pinchartl: goal is this week, just need to finish the VIN vdev registration probe() -> complete() which I hope I will manage today
+09:19 < kbingham> Well hopefully I've saved neg some days :)
+09:20 <@pinchartl> thank you
+09:20 <@pinchartl> kbingham: I think you have :-)
+09:20 < neg> kbingham: lookig at the hoops you jumped for V3M boot you saved me lots of time :-)
+09:21 < kbingham> stooooopid hoops.
+09:22 <@pinchartl> kbingham: feel free to tell Sergei to thread his patches
+09:22 <@pinchartl> next is...
+09:22 <@pinchartl> jmondi: your turn
+09:22 < jmondi> yep
+09:22 < kbingham> Ugh ... and that was annoying too - :D
+09:22 < geertu> Marex: chocolates (in response to marex-cloud)
+09:23 < jmondi> A) - submitted CEU driver to linux media and ported Migo-R to use the new CEU driver
+09:23 < jmondi> - submitted patches for Migo-R and SH4 memory management
+09:23 < jmondi> - resumed gmsl work: re-collecting patches for now and questions to Maxim
+09:24 < jmondi> B) gmsl: several patches I need to rebase and retest
+09:24 < jmondi> - check waht's in Cogent code-drop we have been notified about more than 1 month ago
+09:24 < jmondi> - hope to receive answers from maxim
+09:24 < jmondi> -- eot --
+09:24 < jmondi> that was quick!
+09:25 < kbingham> jmondi: if you're planning to rebase the gmsl patches ... what base are you planning ?
+09:26 < jmondi> kbingham: on top of your stabilization series
+09:26 < jmondi> which currently is not part of gmsl/base
+09:26 < kbingham> aha I see.
+09:26 < jmondi> kbingham: you should send a v2, right?
+09:26 < kbingham> You're not planning to rebase .. .the 'base' then.
+09:26 < kbingham> jmondi: Oh - Do I have work there - I didn't realise ... sorry ... I'll take a look today.
+09:27 < jmondi> kbingham: just trying to remember as well
+09:28 < neg> the base of VIN+CSI-2 should be refreshed if the new base should be v4.15-rc1 due to the different async subnotifer implementations
+09:28 < jmondi> kbingham: GMSL Stabilisation V2
+09:29 < jmondi> it was "v2", it just has "PATCH" in the subject in place of "PATCH v2".. sorry about this
+09:29 < jmondi> neg: yeah, I read your answer from yesterday, thanks... that will be another rebase, for later :)
+09:29 < kbingham> jmondi: Oh - sorry I must have misnumbered the patches.
+09:30 < jmondi> no problem, got confused by the subject :)
+09:31 <@pinchartl> next is...
+09:31 <@pinchartl> me
+09:31 < jmondi> kbingham: you actually have comments on v2... so yes, a v3 is needed somewhen
+09:31 < kbingham> jmondi: Ok - I'll try to do that :)
+09:31 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
+09:31 <@pinchartl> Since last meeting:
+09:31 <@pinchartl> - Posted new version of DU plane boundaries fixes
+09:31 <@pinchartl> - Posted DU dmabuf import fixes
+09:31 <@pinchartl> - Posted V4L2 unbind/userspace race condition handling RFC
+09:31 -!- Irssi: Pasting 8 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
+09:31 <@pinchartl> Until next meeting:
+09:31 <@pinchartl> - More patch review
+09:31 <@pinchartl> - Complete display color keying support for Gen3
+09:31 <@pinchartl> - New version of the DU plane boundaries fixes
+09:31 <@pinchartl> - New version of the V4L2 unbind/userspace race condition handling
+09:31 <@pinchartl> - Test DU dmabuf import fixes locally
+09:31 <@pinchartl> - Start reworking video device registration code
+09:32 <@pinchartl> The goal is to allow video device registration at probe time. As an intermediate step, Hans Verkuil wants video device registration to be split into initialization and registration functions.
+09:32 <@pinchartl> Issues and Blockers: None
+09:32 <@pinchartl> --EOT--
+09:32 <@pinchartl> oh, I forgot to mention I have discussed video device registration issues with Niklas, Sakari and Hans
+09:33 <@pinchartl> Hans still doesn't like registering video devices at probe time, we need to continue working on convincing him
+09:33 < kbingham> when would he prefer they are registered?
+09:33 <@pinchartl> at complete() time
+09:34 < jmondi> pinchartl: I am missing in this discussion why it is bad to register video device at complete() time
+09:34 < jmondi> because "complete()" might never not be called if one subdev fails?
+09:34 < kbingham> Ahh .. I guess this would put me on the 'probe' side too then ... because I want device to exist if they exists :)
+09:34 < neg> pinchartl: just a heads up for your unbind/bind race condition testing, whith the next VIN patches this will be borked as the registration is moved to complete() so using that for testing won't work :-(
+09:35 <@pinchartl> his opinion is that the driver should be fully ready to be used as soon as video device nodes appear, as userspace currently relies on this behaviour
+09:35 <@pinchartl> neg: I know :-/ I wanted to test it on subdevs, but subdev registration is ever more broken
+09:35 < kbingham> pinchartl: Is this discussion on ML or IRC?
+09:35 < kbingham> (*was)
+09:35 <@pinchartl> and I don't think we should fix it, as the goal is to replace subdev nodes with the request API
+09:36 <@pinchartl> kbingham: IRC
+09:36 <@pinchartl> partly in #v4l, partly in #rcar-vin
+09:36 < kbingham> Ahh ok.
+09:36 <@pinchartl> (the latter for a private discussion with Niklas and Sakari)
+09:36 < kbingham> :D
+09:38 <@pinchartl> that's it for status reports
+09:38 < neg> pinchartl: at least the device reattach() code is now removed :-) I cried a bit when I found that gem
+09:38 <@pinchartl> anything else to discuss ?
+09:39 < neg> Out of curiosity I'm interested in the current goal for GMSL work
+09:39 < jmondi> not really, it's a bit too early to discuss about meetings I guess..
+09:39 < kbingham> neg: Make it actually work ? :)
+09:40 < neg> I have no planed work for that in Q4 other then to provied a new base for jmondi, but wondering if someone is expecting me to do anything else in this area
+09:40 < jmondi> neg: I think I'm the only one with gmsl work this batch... on my side I have to "make frame sync happen"
+09:40 < jmondi> or at least try to
+09:40 <@pinchartl> neg: you're good for Q4 :-)
+09:41 < kbingham> neg: You mean aside from providing V3M VIN routing / :)
+09:41 < neg> kbingham: :-)
+09:43 <@pinchartl> As Core and I/O have skipped this meeting, the next joint meeting will be held one week from now, on Thursday 2017-11-30 at 08:00 GMT / 09:00 CET / 10:00 EET / 17:00 JST. We will have a brief Multimedia meeting at 09:00 GMT / 10:00 CET / 11:00 EET / 18:00 JST which you can skip if you have nothing to report (in this case please notify me on the periperi mailing list beforehand).
+09:44 < kbingham> When should we plan #PeriMediaSnowConf :)
+09:46 <@pinchartl> that's a very very good question
+09:46 <@pinchartl> it would be the week after the FOSDEM
+09:46 <@pinchartl> would you like to help me organizing it ? :-)
+09:48 < jmondi> pinchartl: let's share effort... maybe starting with an email for a call for partecipants, should we?
+09:49 < neg> I don't know much about the alps but tried to get information from a friend the other day and without a location in mind I could not get much other then week 6 (feb 05-11) is the week where prices starts to spike for the season acording to him
+09:50 <@pinchartl> the French winter school holidays start on February the 10th, so that's usually when prices rise
+09:51 <@pinchartl> (and were the slopes get crowded)
+09:51 < neg> And I agree with jmondi a mail thread would be good to start locking things down such as time, location and partecipants :-)
+09:52 <@pinchartl> I'll send you
+09:52 <@pinchartl> today
+09:53 <@pinchartl> so that's it for today
+09:53 <@pinchartl> thank you all for attending
+09:53 < kbingham> cheers all.