path: root/wiki/Chat_log/20160419-mm-chatlog

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]