Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 663 insertions, 0 deletions

diff --git a/wiki/Chat_log/20160419-mm-chatlog b/wiki/Chat_log/20160419-mm-chatlog
new file mode 100644
index 0000000..b509629
--- /dev/null
+++ b/wiki/Chat_log/20160419-mm-chatlog
@@ -0,0 +1,663 @@
+Multimedia-chat-meeting-2016-04-19
+
+<pinchartl> goooooood morning !  [15:54]
+<neg> morning
+<pinchartl> or afternoon
+<uli___> hello  [15:55]
+<dammsan> hi guys
+<morimoto> hi
+<pinchartl> we have everybody, perfect  [15:57]
+<pinchartl> let's get started
+<pinchartl> (sorry, I was opening the tasks list)
+<pinchartl> agenda for today
+<pinchartl> Topic 1. Status check for the multimedia tasks  [15:58]
+<pinchartl> Topic 2. Additional '50%' tasks
+<pinchartl> Topic 3. Next meeting
+<pinchartl> anything else ?
+<pinchartl> I'll take that as a no  [15:59]
+<pinchartl> Topic 1. Status check for the multimedia tasks
+<pinchartl> let's handle that in alphabetical order  [16:00]
+<pinchartl> we have, for Magnus
+<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen2
+<pinchartl> VIN,?,plan,magnus,IPMMU integration on Gen3
+<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen2
+<pinchartl> VIN,?,plan,magnus,IPMMU support on Gen3
+<dammsan> no progress so far =)
+<pinchartl> ok, that's an easy one :-)  [16:01]
+<pinchartl> now, for Morimoto-san
+<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI sound Prototype on Gen3
+<pinchartl> RSND,2016-06-30,plan,morimoto,HDMI sound Upstream support without
+            hotplug on Gen2
+<pinchartl> RSND,2016-09-30,plan,morimoto,Hotplug support upstream on Gen3
+<morimoto> I'm fighting with them
+<morimoto> I noticed it can be 3 step
+<morimoto> 1. DT graph  [16:02]
+<morimoto> 2. HDMI + ASoC
+<morimoto> 3. RSND support
+<morimoto> I sent prototype patch for 1.
+<morimoto> and got any response
+<pinchartl> I've seen that. would you like me to review it ?
+<morimoto> Thanks, but it seems OK now  [16:03]
+<morimoto> I think I understand graph concept
+<morimoto> but, not yet understand motivation
+*** horms_ (~horms@124-171-1-229.dyn.iinet.net.au) has joined channel
+    #periperi
+<pinchartl> that I can explain
+<morimoto> please  [16:04]
+<pinchartl> it came from V4L2
+<morimoto> Yeah, I know. my motivation means
+<pinchartl> complex camera devices are made of multiple hardware devices
+<pinchartl> camera sensor, CSI receiver, ISP, lens controller, flash
+            controller, ...
+<pinchartl> those devices can be inside the SoC or on-board  [16:05]
+<pinchartl> and they can be mixed and matched on different SoCs/boards
+<pinchartl> so we have, in V4L2, a framework to support them using multiple
+            drivers
+<pinchartl> it's a bit similar to ASoC
+<pinchartl> when we had to create DT bindings
+<pinchartl> we needed a way to express how the devices were connected together
+            from a data flow point of view
+<pinchartl> like saying that the camera sensor output is connected to the
+            input of CSI-2 receiver 2  [16:06]
+<pinchartl> or that the output of CSI-2 receiver 0 is connected to input 3 of
+            the ISP
+<pinchartl> essentially, that's expressing a graph of data flow connections
+<pinchartl> hence the OF graph bindings  [16:07]
+<pinchartl> a device represented in DT can have multiple ports
+<pinchartl> those are connection points through which data flows
+<pinchartl> and to represent connections between ports, we use endpoints
+<pinchartl> and endpoint repreent one end of a connection  [16:08]
+<pinchartl> we need the endpoints because a port on one DT node can be
+            connected to ports of multiple other DT nodes
+<pinchartl> is that clearer ?
+<morimoto> 80%  [16:09]
+<morimoto> I understand that the connection is very complex.
+<morimoto> but my question is
+<dammsan> pinchartl: do the ports map directly to hardware?
+<pinchartl> yes they do
+<pinchartl> so do the connections
+<dammsan> morimoto-san was saying?  [16:10]
+<morimoto> my question is
+<morimoto> 1) we can happy to find-out its connection when probing timing ?
+<morimoto> 2) does graph supports runtime switching ??
+<morimoto> do we would like to find its connection on probe timing ??
+<morimoto> we can use phandle for connection itself ?  [16:11]
+<morimoto> (for 1. question)
+<pinchartl> I'm not sure to understand the first question
+<morimoto> I think phandle can do that ?  [16:12]
+<morimoto> if we would like to know "connection"
+<pinchartl> we use phandles to describe connections
+<pinchartl> a connection is a link between two ports
+<pinchartl> it's represented as a phandle to an endpoint  [16:13]
+<pinchartl> the endpoint on one side of the connection references the endpoint
+            on the other side through a phandle, with the remote-endpoint
+            property
+<morimoto> Is this means, driver want to know who is connected, on probe time
+           ?  [16:14]
+<morimoto> or which channel is used ?
+<pinchartl> that's what drivers usually do
+<pinchartl> note that the connections in DT describe the possible hardware
+            connections  [16:15]
+<pinchartl> not the active connections at a given point of time
+<pinchartl> DT will tell that device A and device B are connected at the
+            hardware level
+<pinchartl> it will not tell whether the connection is currently in use
+<pinchartl> so DT will show all possible connections
+<morimoto> "all possible connections"  [16:16]
+<morimoto> is this the purpose of graph ?
+<pinchartl> the purpose of the graph is to describe how the hardware pieces
+            are connected together
+<pinchartl> that's all
+<morimoto> Hmm...
+<morimoto> OK, and it indicate connection only  [16:17]
+<morimoto> can't do runtime switch
+<pinchartl> it certainly doesn't handle that, no
+<pinchartl> you can't modify connections at runtime  [16:18]
+<morimoto> OK
+<dammsan> pinchartl: if you want to perform a run time switch, what do you
+          use?
+<pinchartl> unless you solder new wires to the board to create new connections
+<pinchartl> but I think that's out of scope :-)
+<pinchartl> runtime activation or deactivation of a connection is left for the
+            driver to handle, it doesn't involve DT
+<pinchartl> DT describes the hardware
+* geertu is dreaming of DT overlays...  [16:19]
+<dammsan> sure, i understand
+<pinchartl> it describes how the data signals are routed on the board or in
+            the SoC
+<dammsan> but how does the typical driver perform activation/deactivtation?
+<pinchartl> it's subsystem-specific  [16:21]
+<dammsan> ok i see
+<dammsan> thanks
+<pinchartl> even the concept of connection activation/deactivtation? is
+            subsystem-specific
+<morimoto> my patch was super quick hack for ASoC, not good for full-graph.
+<morimoto> my patch reviewer said that current ASoC style is not good match to
+           graph style
+<pinchartl> it's not defined by the DT bindings
+<pinchartl> who reviewed it ?
+<morimoto> Jean-Francois Moine  [16:22]
+<pinchartl> did
+<morimoto> it seems he is working for this graph + ASoC from last year
+<pinchartl> did Lars comment too ?
+<morimoto> No comment from Lars
+<morimoto> graph + ASoC patch was posted last year, but not accepted  [16:23]
+<morimoto> and he said (if my understanding was correct)
+<morimoto> it need different style  [16:24]
+<morimoto> total
+<morimoto> in total
+<morimoto> I couldn't understand what is the next step for graph + ASoC
+                                                                        [16:25]
+<pinchartl> did he explain what different style ?
+<morimoto> Current ASoC is using CPU driver + Codec driver + Card driver
+<morimoto> but (if my understanding was correct)  [16:26]
+<morimoto> graph + ASoC doens't need Card driver
+<morimoto> And CPU driver needs update
+<morimoto> in my understand
+<pinchartl> that's correct I believe  [16:27]
+<morimoto> I need more investigate this topic
+<morimoto> DT point <-> Code point
+<morimoto> I think this is the reason why ASoC had Card driver...  [16:28]
+<morimoto> OK, this is current my DT issue
+<pinchartl> yes, the card driver is similar in purpose to the OF graph DT
+            bindings  [16:29]
+<morimoto> Ahh, OK, this is understandable comment for me
+<morimoto> :)
+<morimoto> I couldn't 100% understand why graph is needed, because ASoC
+           already had Card :)  [16:30]
+<morimoto> And, next 2. HDMI + ASoC
+<pinchartl> the idea is that video uses the OF graph DT bindings
+<pinchartl> and alsa has the ASoC DT bindings
+<pinchartl> and now that we have a connector that can carry both video and
+            audio, we need to connect the two
+<pinchartl> that's the issue
+<pinchartl> two totally different DT binding concepts that need to be
+            connected together  [16:31]
+<morimoto> I think it is not easy
+<morimoto> above Jean-Francois had tring this issue
+<morimoto> but not yet accepted  [16:32]
+<morimoto> and next HDMI sound + ASoC, I know Russel added dw-hdmi-ahb-audio
+           driver  [16:34]
+<morimoto> I think DU is using dw-hdmi-bind() function
+<morimoto> above is related to it.
+<morimoto> I think this driver seems have compatible  [16:35]
+<morimoto> but,
+<morimoto> the data flows is not same as our chip
+<morimoto> and our datasheet doesn't indicate detail
+<morimoto> dw-hdmi-ahb-audio is using mem -> DMA -> chip  [16:36]
+<pinchartl> there's no proper upstream solution at this point. Russell
+            sometimes has, let's say, very personal and peculiar ideas when it
+            comes to DT bindings or driver framework designs
+<morimoto> our case, mem -> SSI -> chip
+<pinchartl> by DMA do you mean DMA engine ?
+<morimoto> not DMAEngine, it seems this chip has DMA inside  [16:37]
+<pinchartl> as in the Linux DMA engine API
+<pinchartl> ok
+<pinchartl> dw-hdmi-ahb-audio might need to be reworked
+<morimoto> but our datasheet doesn't show it 
+<pinchartl> I haven't looked at it, I don't know how it works
+<morimoto> it seems this chip is supporting many data transfer style
+<morimoto> anyway, I'm asking detail to HW team  [16:38]
+<pinchartl> ok
+<pinchartl> regarding the OF graph DT bindings
+<pinchartl> we need to solve the problem of two separate DT bindings existing
+            for video and audio
+<pinchartl> I don't know what will be accepted upstream  [16:39]
+<pinchartl> it's an open issue, nobody has solved it upstream yet
+<morimoto> yeah
+<morimoto> I think it is not easy ?
+<pinchartl> so I'm afraid this needs new designs, new ideas, and lots of
+            discussion to agree on a solution with everybody
+<pinchartl> it's certainly not easy, no  [16:40]
+<morimoto> Do you think this is 1st priority ?
+<morimoto> Or should I create prototype as 1st step ?
+<pinchartl> DT bindings are a stable ABI, so they are a prerequisite for
+            upstream merge
+<morimoto> prototype = HDMI can use sound somehow
+<pinchartl> you can certainly create a prototype  [16:41]
+<pinchartl> if we want to convince people about a given DT bindings scheme we
+            have to show that it works, and how it works
+<pinchartl> so an implementation is needed
+<morimoto> Sorry, my prototype means skip DT at this point, and work to HDMI
+           sound output as 1st  [16:42]
+<pinchartl> you can do that, but it can't be merged upstream without DT
+            bindings
+<morimoto> Yes, prototype is needed to discussion
+<morimoto> Yes.
+<morimoto> So, this DT issue is my 1st priority  [16:43]
+<pinchartl> DT bindings take time to be discussed and agreed on
+<pinchartl> so it makes sense to start early
+*** wsa_ (~wsa@p4FE25DE7.dip0.t-ipconnect.de) has joined channel #periperi
+<morimoto> OK, will try
+<pinchartl> but while discussions are ongoing, a prototype of sound support
+            can certainly be written  [16:44]
+<pinchartl> the runtime side doesn't depend on DT
+<pinchartl> only probind does
+<morimoto> I think DT is big issu  [16:45]
+<morimoto> issue
+<morimoto> HDMI + ASoC is big issue
+<morimoto> SSI HDMI supoort is not a big issue
+<pinchartl> I think I agree, although changes to the dw-hdmi-ahb-audio driver
+            might not be very easy to get past Russell  [16:46]
+<morimoto> OK, thanks  [16:47]
+<morimoto> this is current my headache, oops, progress
+<pinchartl> :-)
+<pinchartl> so what's your plan ? create a prototype in parallel to the DT
+            bindings discussions ?  [16:48]
+<morimoto> parallel ?
+<morimoto> Yah yes
+<pinchartl> at the same time
+<morimoto> DT bindings discussions + HDMI sound prototype code, do you mean ?
+                                                                        [16:49]
+<pinchartl> yes
+<morimoto> yes
+<morimoto> Can you separate todo list for me ?  [16:51]
+<morimoto> DT + dw-hdmi-ahb-audio + SSI
+<pinchartl> split "RSND,2016-06-30,plan,morimoto,HDMI sound Prototype on Gen3"
+            in three ?
+<morimoto> Yes  [16:52]
+<pinchartl> ow about
+<pinchartl> RSND,2016-06-30,plan,morimoto,DT bindings for HDMI sound
+<pinchartl> RSND,2016-06-30,plan,morimoto,dw-hdmi-ahb-audio prototype on Gen3
+<pinchartl> RSND,2016-06-30,plan,morimoto,SSI prototype on Gen3
+<pinchartl> (s/ow/how/)
+<morimoto> SSI prototype -> SSI + HDMI support prototype  [16:53]
+<morimoto> is understandable.
+<morimoto> other 2 are nice for me
+<pinchartl> ok
+<pinchartl> I'll do that
+<morimoto> thanks
+<pinchartl> anything else for audio ?
+<morimoto> nothing
+<pinchartl> ok  [16:54]
+<pinchartl> next, Niklas
+<pinchartl> ADV7482,v4.7,plan,niklas,Prototype on Gen3
+<pinchartl> ADV7482,v4.8,plan,niklas,Gen3 support upstream
+<pinchartl> ADV7482,v4.8,plan,niklas,Interlace support upstream
+<pinchartl> VIN,?,plan,niklas,Gen3 support
+<pinchartl> VIN,?,plan,niklas,Scaler support (on Gen3)
+<pinchartl> VIN,v4.7,plan,niklas,CSI2 prototype (Gen3)
+<pinchartl> VIN,v4.7,public,niklas,New VIN driver without soc-camera (tested
+            on Gen2)
+<pinchartl> VIN,v4.8,plan,niklas,CSI2 interlace support upstream (Gen3)
+<pinchartl> VIN,v4.8,plan,niklas,CSI2 support upstream (Gen3)
+<pinchartl> VIN,v4.8,plan,niklas,Gen3 support upstream (without CSI-2)
+<neg> VIN on Gen2 on track, will need another patch Hans extended the test
+      suite so minior work left  [16:55]
+<pinchartl> :-)
+<neg> started on VIN on Gen3, prorted the adv7482 and csi2 from BSP and it
+      compiles  [16:56]
+<neg> had a fight with cpg but think I understand it now
+<neg> so next is to fix up DT and update rcar-vin to support multiple subdevs
+                                                                        [16:57]
+<pinchartl> ok
+<pinchartl> do you know how you will do that, or do you need guidance ?
+                                                                        [16:58]
+<neg> current problem is to figure out for which subdevice calls i need to use
+      v4l2_device_call_until_err instead of v4l2_subdev_call but I have not
+      yet read the code so it might be obvious then
+<pinchartl> as you're limited to two subdevices, v4l2_device_call_until_err()
+            might not be the best choice  [16:59]
+<pinchartl> at least not for all operations
+<pinchartl> some of them will likely need to be called manually
+<pinchartl> for things like s_stream you will likely want to control the order
+                                                                        [17:00]
+<pinchartl> call s_stream(1) on the CSI-2 receiver first, and then on the
+            ADV7482
+<pinchartl> as you're limited to two subdevs, and one of them is internal to
+            the SoC, custom code might be a better option than trying to be
+            too generic  [17:01]
+<neg> ok so you think its best not to use a list for subdevs but instead make
+      explicit struct variables for them since I'm limited to only two?
+<pinchartl> I think so, yes  [17:02]
+<pinchartl> we can revisit that later if needed, if we need to support more
+            than two subdevices
+<neg> ok good input, I was looking at the xilinx driver but I can agree to
+      that it's a bit over complex for only two subdevs  [17:03]
+<pinchartl> but I can almost guarantee that any generic code you write now
+            with two subdevices as the only test case won't be generic enough
+            :-)
+<neg> :)
+<pinchartl> it's a very complex problem, let's not try to solve it now
+<pinchartl> or even ever, at least until we need to
+<neg> ok then I feel I'm on track. Will focus on Gen3 VIN first then CSI2 and
+      last ADV7482  [17:04]
+<pinchartl> perfect
+<pinchartl> anything else ?
+<neg> nope I think I'm good
+<pinchartl> great
+<neg> thanks
+<pinchartl> next, me  [17:05]
+<pinchartl> DU,?,plan,laurent,DU+VSPD Integration in Renesas drivers (Gen3)
+<pinchartl> DU,?,plan,laurent,IPMMU integration on Gen3
+<pinchartl> DU,?,plan,laurent,IPMMU support on Gen3 (through VSPD+FCP)
+<pinchartl> DU,v4.7,public,laurent,VSPD Z-order support upstream (Gen3)
+<pinchartl> a large patch series for the VSP driver, needed for DU support,
+            was accepted upstream  [17:06]
+<pinchartl> I'll rebase the integration patches and resubmit them
+<pinchartl> geertu: if you're here, is the power domain patch on track ? when
+            do you expect it to be merged ?
+<pinchartl> anyway, I'll rebase and resubmit  [17:08]
+<geertu> pinchartl: I have to integrate the small comments from Ulf, push out
+         a stable branch for the clock people (who didn't comment so far) that
+         Simon can pull, too
+<pinchartl> geertu: thanks
+<pinchartl> when do you expect it to be merged ?
+<geertu> pinchartl: After that Simon can apply all of it. I'll do the branch
+         tomorrow
+<geertu> pincahrtl: If everything goes well, the end of the week? (depends on
+         clock people)  [17:09]
+<pinchartl> \o/
+<pinchartl> that would be very nice
+<pinchartl> regarding IPMMU integration, no progress
+<pinchartl> Z-order support is public, I'll send a pull request  [17:10]
+<morimoto> pinchartl: BSP team is very waiting Request API Test Program. when
+           can we receive it ?
+<pinchartl> morimoto: let me continue going through the list, I'll address
+            that  [17:11]
+<pinchartl> VSP,?,plan,laurent,Fixed alpha support (VI6_DPR_*_ROUTE.FXA)
+<pinchartl> VSP,?,plan,laurent,UDS regression fix
+<pinchartl> VSP,v4.8,plan,laurent,Fix suspend/resume crash
+<pinchartl> VSP,?,plan,laurent,CLU WARN_ON fix
+<pinchartl> VSP,?,plan,laurent,CLU 2D and 3D mode support
+<pinchartl> VSP,?,plan,laurent,CLU/LUT test application
+<pinchartl> VSP,?,plan,laurent,CLU/LUT upstream API
+<morimoto> ok
+<pinchartl> none of that has been started. suspend/resume and CLU are covered
+            by additional tasks  [17:12]
+<pinchartl> there's
+<pinchartl> VSP,v4.7,public,laurent,CLU/LUT support submitted upstream on Gen3
+<pinchartl> too
+<pinchartl> that's also covered by an additional task for June, so it will be
+            in v4.8, not v4.7
+<pinchartl> VSP,v4.7,public,laurent,Plane alpha + pixel alpha (on Gen3)
+                                                                        [17:13]
+<pinchartl> I think that one has been merged, let me check  [17:14]
+<pinchartl> yes it has  [17:15]
+<pinchartl> VSP,v4.8,plan,laurent,HGO operation mode selection
+<pinchartl> VSP,v4.8,plan,laurent,HGO support upstream on Gen3
+<pinchartl> VSP,v4.8,plan,laurent,HGO test application
+<pinchartl> covered by an additional task too, on track
+<pinchartl> it could possibly make it early to v4.7, but no guarantee yet at
+            this point, it will depend on the review process  [17:16]
+<pinchartl> VSP,?,prototype,laurent,V4L2 request API upstream
+<pinchartl> VSP,v4.8,public,laurent,V4L2 request API usable prototype
+<pinchartl> the test application I'm using now has already been provided to
+            Renesas  [17:17]
+<pinchartl> there's another one in development by Intel
+<morimoto> provided to whom ?  [17:18]
+<pinchartl> they plan to release it but the timing is unclear. it's currently
+            blocked by paper work, and is expected to be released either at
+            the end of this month or at mid-May
+<pinchartl> let me check who I sent it to
+<morimoto> thanks  [17:19]
+<pinchartl> instructions were sent to
+<pinchartl> 	HARUNOBU KUROKAWA <harunobu.kurokawa.dn@renesas.com>  [17:20]
+<pinchartl> CC:	Takanari Hayama <taki@igel.co.jp>, TOSHIAKI KOMATSU
+            <toshiaki.komatsu.ud@renesas.com>, Hisao Munakata
+            <hisao.munakata.vt@renesas.com>, Magnus Damm
+            <magnus.damm@gmail.com>, Ryu Nagasawa
+            <ryu.nagasawa.wg@renesas.com>, TOMOHIRO KOMAGATA
+            <tomohiro.komagata.aj@renesas.com>, Tadahiro Takahashi
+            <tadahiro.takahashi.jz@renesas.com>, KOJI MATSUOKA
+            <koji.matsuoka.xm@renesas.com>, KOUEI ABE
+            <kouei.abe.cp@renesas.com>, NAOYA SHIIBA <naoya.shiiba.nx@
+<pinchartl> "Re: VSP performance enhancements - Documentation"
+<pinchartl> 11/02/2016 01:22
+<pinchartl> that uses a modified version of the media-ctl application
+<pinchartl> and a modified version of the yavta application
+<morimoto> OK, KUROKAWA-san is using this
+<morimoto> (He is here now :)
+<morimoto> But not yet working correctly  [17:21]
+<morimoto> (on renesas-driver branch)
+<pinchartl> I've rebased all the patches locally
+<pinchartl> and will resubmit them to renesas-drivers
+<morimoto> thanks
+<pinchartl> and of course test them with the procedure I've explained in that
+            e-mail
+<pinchartl> I don't expect a new test application to be used at this point
+                                                                        [17:22]
+<pinchartl> I'll fix any issue I find
+<pinchartl> kernel side and user space side if needed
+<pinchartl> we'll switch to the new test application when it will be available
+<pinchartl> but there's no urgency for that
+<morimoto> OK, we would like to test it  [17:23]
+<pinchartl> of course  [17:24]
+<pinchartl> as soon as it's available I'll try it
+<pinchartl> and will then send instructions
+<morimoto> thanks
+<pinchartl> that's it on my side. any other question ?
+<morimoto> when it happen ?
+<pinchartl> the release is expected for end of this month or mid-May  [17:25]
+<pinchartl> (14th of May I believe)
+<pinchartl> it depends on the internal paperwork at Intel
+<pinchartl> developers need to ask permission to release tools publicly
+<morimoto> How about existing test program (?) -> non Intel application ?
+                                                                        [17:26]
+<morimoto> can it be more early ?
+<pinchartl> the program exists already
+<pinchartl> and has been provided, in the e-mail mentioned above  [17:27]
+<morimoto> Yes.
+<pinchartl> as I said, I've rebased the patches, will make sure my test cases
+            work, and submit them to renesas-drivers
+<pinchartl> I don't expect fixes to be needed in user space
+<pinchartl> my target is end of this week for that, weekend at the latest
+                                                                        [17:28]
+<morimoto> Thanks (from KUROKAWA-san :)  [17:29]
+<morimoto> Thanks (from me :)
+<pinchartl> you're welcome
+<pinchartl> apologies for the delay
+<pinchartl> (from me :-))
+<morimoto> np
+<pinchartl> any other question ?
+<morimoto> nothing from me
+<pinchartl> ok
+<pinchartl> I realized I messed up the alphabetical order by the way, I was
+            supposed to go before Niklas  [17:30]
+<pinchartl> sorry about that :-)
+<pinchartl> uli___: you're next
+<uli___> i thought it was per nick
+<uli___> anyway :)
+<pinchartl> DU,?,plan,ulrich,Atomic API test program
+<pinchartl> DU,v4.7,plan,ulrich,HDMI output on Gen3 prototype
+<pinchartl> DU,v4.7,prototype,ulrich,Test setup with HDMI output to HDMI input
+            loopback (without EDID)
+<pinchartl> DU,v4.7,public,ulrich,EDID generation support for the HDMI
+            loopback test setup
+<pinchartl> DU,v4.8,plan,ulrich,HDMI output on Gen3 upstream
+<pinchartl> VIN,v4.7,public,ulrich,Add DV timings support to rcar-vin
+<pinchartl> VIN,v4.7,public,ulrich,Upstream Lager HDMI input bug fixe  [17:31]
+<uli___> on vin, i have trouble understanding hans's comment:
+<uli___> "this just overwrites the adv7180 input with an HDMI input."
+<uli___> https://www.spinics.net/lists/linux-media/msg99554.html
+<uli___> i just don't know what he is referring to  [17:32]
+<pinchartl> I think Hans incorrectly assumes that VIN as both an analog TV
+            input (through ADV7180) and an HDMI input  [17:33]
+<pinchartl> can you ask him what he means ?  [17:34]
+<uli___> just wanted to check if i missed something obvious there
+<uli___> can do
+<pinchartl> nothing obvious to me at least  [17:35]
+<uli___> apart from that, i'm currently working on converting adv7511 and
+         rcar-du to the bridge api
+<uli___> for hdmi out on gen3
+<pinchartl> that has been done already
+<neg> no I agree with pinchartl it looks like he assumes one VIN instance can
+      do both
+<pinchartl> (not by me)
+<pinchartl> see "[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support"
+<pinchartl> I'll try to test it today  [17:36]
+<pinchartl> http://www.spinics.net/lists/linux-arm-msm/msg19839.html
+*** horms_ (~horms@124-171-1-229.dyn.iinet.net.au) has quit: Quit: Leaving
+<uli___> good to know...
+<pinchartl> I should have told you earlier, sorry  [17:37]
+<uli___> how about the du side, is there anything public?  [17:38]
+<pinchartl> "[RFC] drm: rcar-du: Remove i2c slave encoder interface for hdmi
+            encoder"  [17:39]
+<pinchartl> I'll rebase that one too
+<uli___> iirc, you have mentioned before that the dw-hdmi driver does stuff
+         that is the reponsibility of the du driver  [17:40]
+<uli___> is that still the case?
+<pinchartl> it's about creation of the connector  [17:41]
+<pinchartl> I need to check, I don't remember the details, sorry  [17:42]
+<uli___> ok  [17:43]
+<uli___> that'd be the next thing on the to-do list
+<pinchartl> the idea is that the du driver should create the connector
+<pinchartl> but the adv7511 driver, converted to drm_bridge, creates it
+<pinchartl> and so does the dw-hdmi driver
+<pinchartl> I don't like that
+<pinchartl> and have discussed the problem with Archit previously
+<pinchartl> I'll need to check what we agreed on  [17:44]
+<uli___> apart from those, no updates from me
+<pinchartl> ok
+<pinchartl> that's it for topic 1 then  [17:45]
+<pinchartl> topic 2, additional tasks
+<pinchartl> dammsan: would you like to comment on that ?
+<dammsan> uhm, not sure what to say except that stuff has been submitted
+                                                                        [17:49]
+<pinchartl> that's already good :-)
+<dammsan> i trust that pinchartl has discussed with the members about the
+          details
+<pinchartl> yes we have
+<dammsan> for neg and uli we probably need to wait on I/O group tasks
+<pinchartl> well, not with Morimoto-san obviously, as he's free from
+            additional contracts, but with Niklas and Ulrich
+<pinchartl> when do you expect that ?  [17:50]
+<dammsan> i expect wsa to talk to uli and neg about additional i/o tasks
+<dammsan> this will happen this week
+<dammsan> and we will know more next week
+<uli___> dammsan: wsa_ and i have agreed on a task just before
+<wsa_> it happens currently :D
+<dammsan> my take on all this is  that eaach member can chose how much time to
+          spend on tasks for the various groups  [17:51]
+<dammsan> i/o and multimedia gets two chances this quarter
+<dammsan> while core gets one
+<pinchartl> I can see that becoming complex pretty soon
+<dammsan> so uli and neg should talk to the different group leaders about how
+          they want to spend their time  [17:52]
+<wsa_> may I ask something about that?
+<dammsan> sure
+<wsa_> the additional contracts have stricter requirements about deliverables
+       (like the test-setup and the wiki page)
+<wsa_> which I understand
+<wsa_> that makes choosing how much to work for this or that group not really
+       flexible, does it?  [17:53]
+<wsa_> or am I mixing up things?
+<dammsan> a bit  [17:54]
+<dammsan> so each group leader has to figure out what task to allocate
+          depending on the available amount of time     for each guy
+<wsa_> yes  [17:55]
+<dammsan> we have very little time at this point, and with wikis and whatnot
+<dammsan> amount of development time is limited
+<dammsan> but amount of development time for each guy
+<dammsan> is kind of spread out over the groups
+<dammsan> for the leaders i assume they spend the majority of the time on
+          their own group activity  [17:56]
+<dammsan> but for members like uli and neg
+<dammsan> they have tasks for all the groups
+<dammsan> which means also additional tasks for all the groups
+<dammsan> and how to split the time between the groups is something that i
+          think each guy can control
+<dammsan> by talking with the group leaders
+<dammsan> and each group leader needs to encourage people to join his group
+          too =)  [17:57]
+<dammsan> neg: pong?
+<pinchartl> stupid question, why does base task for all groups imply
+            additional tasks for all groups ?
+<dammsan> pinchartl: for additional task i think we can follow the base
+          contract to begin with  [17:58]
+<dammsan> if needed group leaders can extend beyond their own group  [17:59]
+<dammsan> i think pinchartl is needed in the core group
+<dammsan> and i also think that geert is needed by the i/o group
+<dammsan> neg: you can chose how you spend your weeks between the groups for
+          additional tasks  [18:00]
+<wsa_> he definately is
+<dammsan> does that clarify?
+<wsa_> for now, i think so  [18:01]
+<neg> dammsan: ok, but then I might have missunderstod something. I have
+      talked to pinchartl about additional multimeda tasks that would fill my
+      allocated time for additnal tasks. Should I have spread the additonal
+      work also over core and I/O ?
+<pinchartl> dammsan: maybe I'm being thick today, but now that additional
+            tasks for multimedia have been drafted, with an estimation of the
+            time required to complete them, how can developers choose how to
+            allocate their time  [18:02]
+<dammsan> so each guy knows how many weeks in total that are in their current
+          base task
+<dammsan> this is supposed to be 50% of the total time
+<wsa_> i think by doing that neg already chose 100% multimedia group :)
+                                                                        [18:03]
+<dammsan> the same amount of time as the base task is supposed to be assigned
+          to the additional tasks
+<wsa_> 100% of the additional tasks that is
+<geertu> dammsan: aha?
+<dammsan> in my understanding neg is only pinned down to 1/3 of his total time
+          this quarter  [18:04]
+<dammsan> of course pinchartl wants him to do more stuff there
+<dammsan> and i think he is doing good work for multimedia
+<dammsan> neg: if you want to spend 100% of your time with multimedia then you
+          should do that  [18:05]
+<dammsan> but i advice you to keep good relationship with all group leaders =)
+<dammsan> geertu: you and i have not gotten to talk about the core tasks so
+          much yet
+<dammsan> next week  [18:06]
+<dammsan> still completely unclear?
+<dammsan> =)
+<pinchartl> dammsan: it sounds a bit like a big matsuri to me :-)
+<neg> ofc, I can do work where it is most needed. I only assumed after the
+      last multimedia meeting during ELC that my additonal tasks for this
+      quarter was most needed for multimedia
+<wsa_> neg: okay, you go work 100% for multimedia, but buy me a drink at the
+       next conference ;))))
+<pinchartl> neg: that was my assumption too
+<neg> wsa_: ofc :-)
+<pinchartl> to be honest I really don't like the idea of internal competition
+            for time allocation
+<wsa_> that is even my assumption
+<wsa_> i like working with neg, but I don't really have a task for him  [18:07]
+<dammsan> pinchartl: there is no competition
+<dammsan> it is similar to before, each guy gets to tell which group he wants
+          to work with
+<pinchartl> let's see how it will work for this quarter then  [18:08]
+<dammsan> yes
+<dammsan> pinchartl: please note that only the 5/E task for neg is pinned down
+<dammsan> i realise more work is needed, but that's always the casee for all
+          groups when we are resource starved  [18:09]
+<dammsan> jinzai will contact each member with additional contracts later this
+          month
+<dammsan> if there are more questions then please bring em on  [18:10]
+<pinchartl> not from me  [18:11]
+<pinchartl> we should close the meeting. any additional comment anyone ?
+                                                                        [18:12]
+<pinchartl> I'll take that as a no  [18:13]
+<pinchartl> last topic, next meeting  [18:14]
+<pinchartl> keeping the current schedule, that should be on the 3rd of May
+<pinchartl> however, I will be travelling
+<dammsan> can we do + or - 1h offset?
+<dammsan> my schedule tends to collide with this  [18:15]
+<dammsan> but you guys seem ok by yourself, so me being semi-present may not
+          be such a bad idea
+<pinchartl> three options: one week early, one week late, or without me
+<pinchartl> (I'm sorry about that)
+<dammsan> i think you should be present
+<dammsan> i'm ok with the other proposals  [18:16]
+<pinchartl> any preference anyone ?
+<uli___> 9am collides with my sleeping schedule, so i'd vote for +1h :)
+<uli___> i'm not particular with the date
+<neg> +/- 1 Week will collied with the core meeting  [18:17]
+<pinchartl> we can do another day
+<pinchartl> Wednesday for instance
+<neg> works for me
+<uli___> i would actually prefer to have all meetings in one week as well
+<uli___> i mean in the same week
+<pinchartl> I don't think we'll have a lot to talk about in a week  [18:18]
+<pinchartl> so I propose in three weeks
+<pinchartl> I'll send an invitation  [18:19]
+<pinchartl> that's it for today
+<pinchartl> thank you everybody
+<pinchartl> and have a nice day/evening
+<neg> thanks all
+<dammsan> thanks  [18:20]
+<morimoto> bye  [18:22]
+<uli___> bye
+<morimoto> pinchartl: I will put today's log to Redmine, please update
+           peripelist  [18:23]