Multimedia-chat-meeting-2017-05-10

<dammsan> pinchartl: if you could distill some additional task candidates that
	  would be great  [15:59]
<dammsan> but it does not have to happen right now
<pinchartl> that's topic 2 isn't it ? :-)
<dammsan> good point =)
<dammsan> nice that someone is awake at least  [16:00]
<pinchartl> :-D
<pinchartl> let's get started then
<pinchartl> Topic 1. Status check for the multimedia tasks
<pinchartl> jmondi: as you're the last one to have posted your status update,
	    you can start  [16:01]
<jmondi> that's fair
<pinchartl> (not sure whether that will be a good enough incentive to get the
	    reports earlier in the future, let's see)
<jmondi> at least I can still go from the top of my head
<jmondi> A)
<jmondi> - Sent v3 of CEU driver  [16:02]
<jmondi> - Working on Migo-R remote board to have CEU probe at least
<jmondi> - trying to build a local test platform with RZ devices
<jmondi> B)
<jmondi> - I expect a lot of review comments on CEU driver
<jmondi> - Have CEU probe on Migo-R  [16:03]
<jmondi> - Have a test platform where I can at least run mainline and test the
	 driver
<jmondi> C  = D = None
<jmondi> -- eot --
<pinchartl> thank you  [16:04]
<pinchartl> speaking of review comments
<pinchartl> I'd like the rest of the team to feel free to cross-review patches
<pinchartl> I certainly want to review them myself too
<pinchartl> but there's no reason for me to be the only reviewer
<neg> I agree, I will try to do more reviews in MM  [16:05]
<pinchartl> neg: thank you
<dammsan> question: Geert seems to have sent a patch to fix the sh7722 PFC
	  issue, who can test and reply to him?
<kbingham> Also agree here! - I've started with some of Negs ' :) - but that
	   was easy becasuse I was looking at his patches directly.
								        [16:06]
<jmondi> dammsan:  I will
<dammsan> great thanks
<pinchartl> dammsan: I believe that Geert has tested the patches, but it's of
	    course nice to double-check
<pinchartl> jmondi: thank you
<jmondi> I already planned to do so yesterday, but I failed to do so
<dammsan> nice with a tested-by tag
<pinchartl> uli___: as you're second last to have posted your status update,
	    you're next :-)  [16:07]
<uli___> fair enough :)
<uli___> so i did a little stub driver for the max9260 using serdev
<uli___> seems pretty straightforward
<uli___> but it took me a while to figure out that the max9260 always talks
	 uart on the controlling side  [16:08]
<uli___> even though it is capable of both i2c and uart on the same pins
<uli___> anyway, i got my hands on two chips, and i'll wire them up to the
	 salvator-x board
<uli___> and see that i can get it to talk
<uli___> i have vays...  [16:09]
<uli___> scnr
<pinchartl> nice project
<pinchartl> just out of curiosity, what's the MAX9260 package ?
<uli___> tqfp
<uli___> at least mine is
<pinchartl> 0.65mm or 0.80mm ?
<uli___> .65
<pinchartl> that's on the verge of becoming painful  [16:10]
<dammsan> uli___: any reason for not using remote access?
<dammsan> if it is not working let me know  [16:11]
<uli___> nothing wrong with it, i just dislike remote access.
<neg> uli___: Do you mean that the max9260 only can be controlled using uart
      in your setup or at all? Is it still capable of beeing controlled over
      i2c if the hw around it where different?
<uli___> dammsan: i'll try it eventually, of course, but i'd like to have
	 something to yell at first  [16:12]
<dammsan> ok ok
<uli___> neg: on the local side (the one that sends the commands), it is
	 always uart
<uli___> but the link can be configured in both ways, and the other way
	 around, it can talk either uart or i2c
<pinchartl> uli___: are you (or do you plan to) use the serdev API ?  [16:13]
<uli___> i do
<neg> uli___: ahh I see, thanks for the clearification :-)
<uli___> and then i intend to look at the gose vin dt thing  [16:15]
<uli___> that's it for now
<pinchartl> thank you
<pinchartl> next in report order, Morimoto-san  [16:16]
<morimoto> OK
<morimoto> A) What have I done since last time
<morimoto> - Finally Sound OF-graph DT which is needed for HDMI sound was
	   accepted, but not yet applied, because of merge-window.
<morimoto> - BSP team want to use AGL, and has issue on sound. I had worked
	   with them. it seems AGL is using SMACK security, and it seems be
	   reason of sound noise.
<morimoto> - BSP team noticed 24bit sound data noise (not for AGL), and I'm
	   helping for debugging. It seems related to HW issue, but not sure
	   yet.
<morimoto> - BSP team want to use ADSP on ALSA. We will have meeting with them
	   tomorrow.
<morimoto> B) What I plan to do till next time
<morimoto> - Wait OF-graph DT applying. Then, post HDMI sound patch-set
<morimoto> - post stalled patches (because of OF-graph) to ML
<morimoto> - Help BSP team
<morimoto> C) Problems I have currently
<morimoto> D) Posted/Accepted bugfix patch
<morimoto> No, sir
<morimoto> --EOT--
<pinchartl> thank you
<pinchartl> looks like the BSP team always needs your help  [16:17]
<pinchartl> you're becoming their super hero :-)
<morimoto> pinchartl: Unfortunately
<pinchartl> you have in your status report e-mail enquired about multiple work
	    items, let's go through them  [16:18]
<pinchartl> * Fence for VSP
<pinchartl> this is not in my base task, as I have (at least temporarily)
	    retired from V4L2 upstream development due to conflicts with the
	    V4L2 maintainer
<pinchartl> however
<pinchartl> while I don't want to jinx it by making early announcements
								        [16:19]
<pinchartl> I hope to get confirmation at the end of the week that things will
	    get moving forward in V4L2
<pinchartl> with a setup of co-maintainers proposed to Mauro
<pinchartl> please keep this information to yourselves for now  [16:20]
<pinchartl> Mauro isn't aware of it yet
<pinchartl> if it works out well, I will be able to go back to working on
	    upstream MC and V4L2 APIs
<neg> :-) (wish I could show a bigger smile over irc)  [16:21]
<pinchartl> :-)
<pinchartl> I don't expect things to be easy though, but there might be hope
<morimoto> I don't understand detail of your V4L2 problem, but I hope
	   everything goes to happy direction
<pinchartl> morimoto: in a nutshell, the conflict between the V4L2 maintainer
	    and me got so bad that I had to stop working on upstream V4L2
								        [16:22]
<pinchartl> because I had to stop interact with him at all
<morimoto> him = Mauro ?
<pinchartl> yes
<morimoto> OK, so, this means Fence will be delay  [16:23]
<morimoto> ?
<pinchartl> in the best case, delayed. in the worst case, if we don't succeed
	    moving forward on V4L2, it could be delayed undefinitely
								        [16:24]
<pinchartl> at least for upstream
<pinchartl> s/undefinitely/infinitely/
<pinchartl> fences support in V4L2 requires API extensions  [16:25]
<pinchartl> and at this time I can't propose new API extensions
<pinchartl> because the maintainer rejects all my proposals
<morimoto> Wow !! very serious !
<pinchartl> yes :-)  [16:26]
<pinchartl> it's been going on for too long
<pinchartl> so I've spent the last month or so to try and find a solution by
	    discussing the problem with many other V4L2 developers
<pinchartl> if all goes well we will propose something in the next few weeks
								        [16:27]
<morimoto> OK, nice to know
<pinchartl> I'm sorry for the delay and inconvenience all this is causing, but
	    there was no other option  [16:28]
<pinchartl> * DU Fence is missing about asynchronous
<pinchartl> I saw the e-mail you sent a few days ago, I'll investigate and
	    reply to it soon
<morimoto> Thank you
<pinchartl> * Cache (DMA ATTR SKIP CPU) problem  [16:29]
<pinchartl> it's on my to-do list for the next two weeks
<pinchartl> I'll rebase the code
<morimoto> Thanks
<dammsan> may i interrupt about this topic?
<pinchartl> dammsan: sure  [16:30]
<dammsan> it seems to me that the DMA_ATTR_SKIP_CPU prototype patch is a local
	  reaction to insufficient performance or R-Car Gen3
<pinchartl> dammsan: partly
<dammsan> however the root cause for this issue seems ignored
<pinchartl> the root cause isn't ignored. we're moving forward with cache
	    handling support in V4L2 and DRM  [16:31]
<dammsan> at least i was told that the performance on Gen2 is different than
	  Gen3 and because of that this patch was created
<pinchartl> I started with the V4L2 side
<pinchartl> Sakari took my latest patch series and posted a new version a few
	    days ago
<pinchartl> I plan to review it
<dammsan> yeah ithink i know what the plan is
<pinchartl> so we're moving forward with fixes for the root causes
<dammsan> but i feel that randomly adjusting cache policy might not be the
	  best solution
<pinchartl> but in the meantime I think that using DMA_ATTR_SKIP_CPU makes
	    sense
<dammsan> do we know how the performance is affected?  [16:32]
<pinchartl> yes
<pinchartl> the issue is that
<pinchartl> the VSP driver handles the cache
<pinchartl> and performs a cache cleaning
<pinchartl> while the memory is actually mapped uncached  [16:33]
<pinchartl> so it makes sense to set DMA_ATTR_SKIP_CPU because the memory is
	    always mapped uncached
<dammsan> well, i can somewhat agree to that
<dammsan> but i don't understand why this is needed on Gen3 and not on Gen2
<pinchartl> this will need  to be revisited when we'll implement support for
	    cached mappings in the DU driver
<pinchartl> on Gen2 the buffers are allocated in the V4L2 framework  [16:34]
<dammsan> of course the architecture has changed
<pinchartl> sorry, I'm mixing two thinks
<pinchartl> s/thinks/things/
<pinchartl> on Gen2 DU doesn't use the VSP
<dammsan> i just want to avoid papering over things
<pinchartl> the VSP driver function where we need to set DMA_ATTR_SKIP_CPU
	    isn't called at all on Gen2  [16:35]
<dammsan> so this is for the DU?
<pinchartl> yes it's for the DU
<dammsan> ok
<dammsan> and it is not needed with V4L2 VSP
<dammsan> if so i'm ok
<pinchartl> for V4L2 VSP buffers are handled by videobuf2 and we already do
	    the right thing
<dammsan> gotcha thanks  [16:36]
<pinchartl> you're welcome
<pinchartl> cache issues are always complex  [16:37]
<pinchartl> * Request API
<pinchartl> for the same reason as explained with fences support, I had to
	    stop working on this upstream  [16:38]
<pinchartl> I thus passed the project to Google
<pinchartl> Alexandre Courbot (ex-NVidia, he now works for Google Japan) has
	    taken over
<pinchartl> I've had a few meetings with him to discuss the implementation
<morimoto> Wow ! So, you don't work for "Request API" anymore ?  [16:39]
<pinchartl> no I don't
<pinchartl> I had to stop all V4L2 upstream API work  [16:40]
<pinchartl> I've explained that before (about a month ago I think, or even a
	    bit more)
<pinchartl> but clearly not well enough as you're now surprised
<pinchartl> I'm sorry about that
<dammsan> i think i explained this to Morimoto-san before as well  [16:41]
<morimoto> OK
<dammsan> but we may have some language barrier
<morimoto> Yes, I think so
<morimoto> I'm sorry too
<pinchartl> it's a very unfortunate situation and I did all I could to avoid
	    it, but unfortunately all I could wasn't enough
<pinchartl> but I didn't want to give up either, which is why I spent the last
	    month trying to find a way to short-circuit the V4L2 maintainer
								        [16:42]
<pinchartl> again, I can't announce anything yet, but I hope to receive a
	    confirmation by the end of this week that we'll propose a
	    co-maintainer setup for V4L2
<pinchartl> I don't expect Mauro to easily accept it though, but we're doing
	    all we can to propose a gradual and smooth transition to maximize
	    the chances he will accept  [16:43]
<pinchartl> I should be able to tell more next week
<pinchartl> and again, please don't share this outside of the team  [16:44]
<pinchartl> * DU / VSP initialize sequence
<pinchartl> on my to-do list for the next two weeks
<pinchartl> I've already started looking into it, it needs a bit more work
<morimoto> pinchartl: can I share this information to BSP team ?
<pinchartl> you can share the problem, and tell them that we're working on
	    trying to fix it, and that more information is expected by the end
	    of this week  [16:45]
<morimoto> OK, thanks
<pinchartl> but please don't share the fact that we're trying to go for a
	    co-maintainers setup
<pinchartl> * VIN V4L2_FIELD_SEQ_TB/TB feature  [16:46]
<pinchartl> neg: what's your plan ?
<pinchartl> still on your to-do list, based on top of the Gen2 cleanup patches
	    ?  [16:47]
<neg> yes, was hoping to get the cleanups accepted first
<pinchartl> is there anything blocking them beside lack of review ?
<neg> nope
<pinchartl> ok thank you
<neg> as I undertood this was a low prio request, but if that changed I can
      rescedule my plan for V4L2_FIELD_SEQ_TB/TB  [16:48]
<pinchartl> I'll review them this afternoon. can you send me a pointer to the
	    patches by e-mail so that I don't forget ? :-)
<pinchartl> morimoto: what's the priority for V4L2_FIELD_SEQ_TB/TB ?
<neg> sure will do, thanks
<pinchartl> (and I assume it's actually V4L2_FIELD_SEQ_TB/BT, not
	    V4L2_FIELD_SEQ_TB/TB)
<morimoto> pinchartl: priority is not hi  [16:49]
<morimoto> but want to have
<pinchartl> ok. it's definitely on the to-do list
<pinchartl> next, dammsan  [16:50]
<morimoto> TB/TB <-> TB/BT. I'm shame ;)
<pinchartl> (who should actually have been first, as he sent no status report
	    at all ;-))  [16:51]
<morimoto> OK, thanks.  [16:52]
<morimoto> I will share these information with BSP team
<pinchartl> seems we've lost dammsan
<pinchartl> I'll go next in the meantime
<pinchartl> I've reposted the Gen3 HDMI output DT integration patches  [16:53]
<morimoto> Thanks. I will try it
<pinchartl> and asked Simon to merge them when v4.12-rc1 will be released
<pinchartl> I've provided a tag with the patchees
<dammsan> pinchartl: no update here apart from getting Migo-R going
<pinchartl> dammsan: thank you  [16:54]
<pinchartl> now that you're back, I'd like to ask you if you have time for a 5
	    minutes chat on IRC after this meeting ?
<pinchartl> (continuing with my report)  [16:55]
<pinchartl> I've started working on the DU / VSP initialization sequence
								        [16:56]
<pinchartl> I've also reviewed Wolfram and Niklas' proposal for the I2C
	    software architecture for the multi-camera setup
<dammsan> sure
<pinchartl> (I'll reply to Wolfram's e-mail about that)  [16:57]
<pinchartl> last but not least, I've spent a significant amount of time
	    handling the fallout of the V4L2 conflicts
<pinchartl> guiding Google with the request API development  [16:58]
<pinchartl> and trying to find a solution to the human side of the problem
	    with other V4L2 developers
<pinchartl> for the next two weeks, I'll  [16:59]
<pinchartl> - Look into the DU fence issue reported by the BSP team
<pinchartl> - Cache (DMA ATTR SKIP CPU) performance issue with VSP2
<pinchartl> - DU / VSP initialization sequence
<pinchartl> and likely more (patch review hopefully)
<pinchartl> that's it for me
<pinchartl> this closes the first topic
<kbingham> pinchartl: Not quite :)
<kbingham> pinchartl: Not that I mind !
<neg> I would also like to give my status report :-)
<pinchartl> oops sorry :-/  [17:00]
<morimoto> Hehe :)
<pinchartl> I had copied your report in my summary e-mail already
<pinchartl> so I thought you were done :-)
<pinchartl> neg: you're next
<morimoto> In this case, Japanese people uses "orz"
<neg> A)
<neg>  - [PATCH] v4l2-async: add subnotifier registration for subdevices
<neg>  - [PATCH 0/2] media: entity: add operation to help map DT node to media
      pad
<neg>  - [PATCH v4 00/27] rcar-vin: Add Gen3 with media controller support
<neg>  - [PATCH v6 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 support
<neg>  - Meeting with Wolfram to discuss DT bindings for 8-ch setup devices.
								        [17:01]
<neg>  - Continued discussions about the ADV7482 with Kieran.
<neg> B)
<neg>  - Post v2 of incremental v4l2-async and DT node to media patches, work
      done (available in rcar-vin-fwnode-test-3) just need to convince my self
      with more testing before posting.
<neg>  - Post new version of CSI-2 patches (work done (available in
      rcar-vin-fwnode-test-3), more tests.
<neg>  - Act on Sakaris comments on Gen3 VIN driver and repost.
<neg> C)
<neg>  - None
<neg> D)
<neg>  - None
<neg> -- EOT --
<pinchartl> thank you
<morimoto> http://kage-design.com/i/orz1.jpg
<pinchartl> morimoto: I'm working from a cafe this morning. if I did that I
	    think people would look at me in a very weird way :-)  [17:02]
<pinchartl> kbingham: you're last ;)à  [17:03]
<pinchartl> s/;)à/:-)/
<kbingham> Keeping mine quick, and not jsut copying the email - I've been
	   working on ADV, which I feel is making good progress - the main
	   topic at the moment is the async subdevs which need to be matched
	   by the async framework. I'll be proposing a change to the matchings
	   for this framework this week. - Otherwise - the ADV748x driver now
	   has multiple subdevs to represent the entities.
<kbingham> http://janet.linuxembedded.co.uk/board-salvator-mc.png shows the
	   new layouts
<kbingham> Of course Niklas has helped me with several parts of that - so
	   thanks neg :)  [17:04]
<kbingham> I've also been rebasing, reworking, and retesting my older
	   patchsets - 3/5 of which are reposted and pull-requested.
<kbingham> The last two caused me a bit more thought and hopefully will be
	   done soon (partition algorithm work)
<kbingham> Moving forwards over the next two weeks, I expect to see some good
	   progress on the v4l2-async subdev matching proposal (which will
	   require changing all the other users ... ugh) - and I hope that all
	   my existing patchsets will be freshened with an aim for them
	   getting closer to integration  [17:05]
<kbingham> - eot -
<pinchartl> thank you  [17:06]
<pinchartl> jmondi: before I forgot, could you try to document the RZ camera
	    hardware setup you're working on in the elinux.org wiki ?
<pinchartl> s/forgot/forget/  [17:08]
<pinchartl> now we're done with the first topic
<pinchartl> Topic 2. Additional tasks for the second batch of Q2
<pinchartl> dammsan: how would you like to handle this ?
<pinchartl> we now have a working multi-camera setup  [17:09]
<pinchartl> which you considered to be a blocker for the more general
	    additional tasks that I proposed before
<dammsan> right
<dammsan> i'm ok with more generic tasks
<dammsan> but we may have to adjust the outcome?
<pinchartl> how do you mean ?  [17:10]
<jmondi> pinchartl: as soon as I have something assembled together :)
<pinchartl> jmondi: sure  [17:11]
<pinchartl> dammsan: have you disappeared again ?  [17:12]
<dammsan> nah i'm right here sorry  [17:13]
<dammsan> i believe the old proposal included some fixed deliverables
<dammsan> but now kieran is working on the ADV driver
<dammsan> and we have slipped time wise
<dammsan> so some update may be needed to reflect the current state  [17:14]
<pinchartl> sure
<pinchartl> what I propose is
<pinchartl> - updating the plan to take new developments into account
<pinchartl> - creating informal tasks based on the plan for the multi-camera
	    development  [17:15]
<pinchartl> - assigning those tasks to developers
<pinchartl> - for those who would work on the multi-camera setup, going
	    forward with the generic additional task
<pinchartl> - for those who would work on other tasks, creating classic
	    additional tasks  [17:16]
<dammsan> sounds good to me
<pinchartl> I believe you typed the SGTM line before my last item
<dammsan> right, SGTM again =)  [17:17]
<pinchartl> thank you :-)
<pinchartl> so, I'd like to ask you all to provide me with a list of items not
	    related to the VIN multi-camera setup that you think you should
	    work on as additional tasks  [17:18]
<pinchartl> that can be done on IRC or over e-mail
<pinchartl> you can use periperi as a source of inspiration
<pinchartl> and also propose other tasks  [17:19]
<pinchartl> (such as V4L2_FIELD_SEQ_TB/BT for Niklas for instance)
<pinchartl> what I'd like to get from this is a good idea of what you'd enjoy
	    working on
<pinchartl> I'll compile that into a proposal at the end of this week  [17:20]
<dammsan> thanks
<dammsan> if you can get the shared multi-camera task done soonish then i can
	  review this week in the renesas office =)  [17:21]
<dammsan> it is up to you
<pinchartl> dammsan: I'll do my best but it will have to wait for tomorrow
<dammsan> sure, no problem  [17:22]
<pinchartl> thank you
<pinchartl> this closes topic 2
<pinchartl> Topic 3. OSS Japan trip
<pinchartl> Magnus has been very nice and booked a meeting space for us
								        [17:23]
<pinchartl> https://www.airbnb.com/rooms/17013981
<pinchartl> accommodation is also available there
<pinchartl> how is everybody doing with accommodation ?
* kbingham is very excited for the meeting place.
<kbingham> dammsan: Good work on the meeting room :)
<pinchartl> kbingham, neg, jmondi, do you all have a place to stay at a
	    reasonable price ?
<neg> I still have my original booking at conference hotel for 28th May  --
      4th of Jun  [17:24]
<kbingham> I think me and jmondi will have to share a room on the final
	   Saturday night at the conference hotel.
<jmondi> I've been able to reserve the conference hotel for the whole period
	 at a rate very close to the LF proposed one
<kbingham> I don't have a room for arrival - I need to find somewhere else
	   cheap.
<dammsan> kbingham: thanks, we'll se
<dammsan> e how it goes  [17:25]
<jmondi> execept for last day, where price is almost double, but I'll be
	 sharing with kbingham (as he said)
<pinchartl> ok
<pinchartl> dammsan: will you be staying at the Taito-ku building ?
<jmondi> I'm quite proud of my "hotel room reservation"-foo now.. I had to
	 make 5 bookings to have the room at those rates :p
<dammsan> pinchartl: i might do so  [17:26]
<kbingham> morimoto: dammsan: Could you recommend anywhere (in location terms)
	   that is good for a new arrival to Japan for lone-ranger sightseeing
	   upon arrival the weekend before the conference?
<pinchartl> we now need to work on the agenda for the meeting  [17:27]
<pinchartl> I want to have time to do hacking all togther
<pinchartl> but there will also be a more regular meeting
<dammsan> kbingham: asakusa or shibuya or shinjuku?
<pinchartl> so please reply to the meeting report with a list of topics you
	    would like to discuss  [17:28]
<pinchartl> and I will then draft the agenda
<pinchartl> I haven't received any proposal for the Saturday after the
	    conference  [17:29]
<pinchartl> I can decide on something by myself, but I'd really appreciate if
	    you could all take just a bit of time to tell me what you would
	    enjoy seeing/doing  [17:30]
* kbingham enjoys hiking - and seeing cultural / natural aspects.
<pinchartl> I expect feedback from everybody else by e-mail :-)  [17:32]
<neg> You will :-)
<pinchartl> next and last topic, next meeting
<pinchartl> two weeks from now is Wednesday 2017-05-24
<pinchartl> that's the week before the face-to-face meeting
<pinchartl> we could skip it, but I believe it would be useful to keep it, to
	    avoid spending time face-to-face discussing about topic that can
	    be handled during our regular bi-weekly meetings  [17:33]
<kbingham> I agree..., and keeps the pace.
<neg> I agree too try keeping it to the 2 week schedule
<jmondi> agreed  [17:34]
<pinchartl> and also to finalize the agenda
<kbingham> The one following OSS might be worth slipping a week though,
	   otherwise we will all just say "Went to japan"
<pinchartl> so I propose two weeks from now, same time
<neg> works for me
<uli___> ok for me
<jmondi> booked
<kbingham> Ack.
<pinchartl> thank you
<pinchartl> that's it for today
*** horms (~horms@217.111.208.18) has quit: Quit: Leaving
<pinchartl> unless anyone has anything else to discuss, I propose adjourning
	    the meeting  [17:35]
<pinchartl> does anyone second ?
<kbingham> Straight to thirded.
*** horms (~horms@217.111.208.18) has joined channel #periperi
<pinchartl> thank you all for attending, and have a nice day !
<dammsan> thanks, you too
<neg> thanks all, have a good day/evening
<jmondi> see you, thanks!
<uli___> bye
<morimoto> Thanks
ERC>