summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20160419-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/20160419-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/20160419-mm-chatlog')
-rw-r--r--wiki/Chat_log/20160419-mm-chatlog663
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]