diff options
Diffstat (limited to 'wiki/Chat_log/20160419-mm-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160419-mm-chatlog | 663 |
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] |