Multimedia-chat-meeting-2018-03-01

10:27 < pinchartl> let's start the multimedia part
10:27 < pinchartl> quick attendees check
10:27 < pinchartl> jmondi: checked
10:27 < pinchartl> kbingham: checked
10:27 < pinchartl> dammsan: checked
10:27 < pinchartl> morimoto: checked
10:27 < kbingham> mic check 1 2, check 1 2
10:27 < pinchartl> uli___: checked
10:27 < pinchartl> pinchartl: checked
10:27 < pinchartl> so we have a full house today
10:27 < pinchartl> let's start with status updates
10:27 < neg> :-(
10:28 < neg> I'm also here :-)
10:28 < pinchartl> neg: ah yes I forgot to mention, usually I forget Jacopo, I thought I'd forget you this time
10:28 < pinchartl> so that you don't feel left out :-)
10:28 < jmondi> pinchartl: thank you!
10:28 < pinchartl> speaking of Jacopo
10:28 < jmondi> I'll sign your name in my black book now
10:29 < pinchartl> I'll go for alphabetical order this time
10:29 < pinchartl> * Jacopo
10:29 < pinchartl> Since last meeting:
10:29 < pinchartl> - CEU v9/v10/v11: CEU series picked up for v4.17
10:29 < pinchartl> - [PATCH 00/13] media: ov772x/tw9910 cleanup
10:29 < pinchartl> - Briefly tested Kieran D3 DU support
10:29 < pinchartl> - Started looking into removing sh_mobile_camera from other SH boards
10:29 < pinchartl> Until next meeting:
10:29 < pinchartl> - Keep removing soc_camera from SH boards
10:29 < pinchartl> - V3M display support
10:29 < pinchartl> Issues and Blockers: None
10:29 < pinchartl> any comment ?
10:29 < jmondi> not much...
10:29 < jmondi> horms: CEU series has been picked up by Mauro
10:29 < jmondi> so you can pick up the DTS changes now
10:29 < jmondi> that's it
10:30 < pinchartl> thank you
10:30 < pinchartl> * Kieran
10:30 < pinchartl> Since last meeting:
10:30 < pinchartl> - ADV748x support for i2c_new_secondary_device
10:30 < pinchartl> Posted along with CBUS/regmap improvements v2
10:30 < pinchartl> - D3 Enable DU patches sent
10:30 < pinchartl> - vsp1/tlb-optimise/v6 - rebased to linux-media/master
10:30 < pinchartl> Until next meeting:
10:30 < pinchartl> - Work towards getting vsp1/tlb-optimise upstream.
10:30 < pinchartl> - Working on DU/VSPD Interlaced support
10:30 < pinchartl> Issues and Blockers:
10:30 < pinchartl> - Need to get a patch tested on a Wheat board
10:30 < pinchartl> This semi-blocks the changes made to the ADV7511 driver. Sergei@Cogent doesn't 
10:30 < pinchartl> seem to have access to one.
10:30 < pinchartl> The patches have been left untested for a long time now, and the situation 
10:30 < pinchartl> isn't likely to change. Should the [RFT] tag be removed and the patches 
10:30 < pinchartl> reposted ? (Or just ask Simon to merge ?)
10:30 < pinchartl> kbingham: any comment ?
10:30 < pinchartl> regarding the wheat board, I think we can get the patches merged
10:31 < pinchartl> horms: do you want them to be reposted ? (kbingham: I assume they would be reposted unchanged ?)
10:31 < kbingham> I didn't put DU interlaced in the 'since last meeting' but that has been my main task this week - so it has commenced.
10:31 < pinchartl> ok, I'll add that
10:31 < kbingham> pinchartl: And yes-  I have no changes to make except for removing the [RFT] tag
10:32 < horms> pinchartl: if you let me know which patches i.e. here, then I can see if they still apply
10:32 < kbingham> (whcih I think would get stripped when applying anyway)
10:32 < pinchartl> horms: thank you
10:32 < pinchartl> kbingham: I'll let you handle that then
10:32 < kbingham> ack.
10:32 < horms> thanks, email is also fine
10:33 < pinchartl> * Laurent
10:33 < pinchartl> Since last meeting:
10:33 < pinchartl> - New versions of DU LVDS rework (hopefully nearing completion)
10:33 < pinchartl> - Dynamic BRS/BRU allocation in display pipelines
10:33 < pinchartl> Until next meeting:
10:33 < pinchartl> - Get the GMSL patches posted to public mailing lists
10:33 < pinchartl> - Skiing holidays (2018-03-10 to 2018-03-17)
10:33 < pinchartl> Issues and blockers: None
10:33 < pinchartl> and also, until next meeting, getting the DU LVDS rework merged
10:33 < pinchartl> any comment from anyone ?
10:33 < pinchartl> kbingham: should I also add a week of holidays for you ?
10:34 < kbingham> pinchartl: Ah yes-  as of last night yes please :)
10:34 < morimoto> Skiing holidays in ELC timing :)
10:34 < kbingham> Although I will take my laptop ... :D
10:34 < neg> If I post VIN v11 today will you have time to look at the ~7 still not yet acked patches? :-)
10:34 < pinchartl> neg: I think so
10:34 < pinchartl> morimoto: what do you think is best, skiing or ELC ? :-)
10:35 < morimoto> Of course Skiing :)
10:35 < kbingham> ahem - - snowboarding!
10:35 < pinchartl> I wasn't very motivated by going to Po(rt)land in March
10:35 < morimoto> Hehe :)
10:35 < pinchartl> * Magnus:
10:35 < pinchartl> Since last meeting: Nothing
10:35 < pinchartl> Until next meeting: Nothing
10:35 < pinchartl> Issues and blockers: None
10:35 < pinchartl> dammsan: any comment ? :-)
10:35 < morimoto> Hehe :)
10:36 < morimoto> Very nice guy :)
10:36 < morimoto> He is now enjoying small business
10:36 < pinchartl> I'll let him answer later
10:36 < morimoto> Now, he backed
10:36 < pinchartl> * Morimoto-san
10:36 < pinchartl> Since last meeting:
10:36 < pinchartl> - Happy Paper Work
10:36 < pinchartl> - Renesas inside work
10:36 < pinchartl> - Answered some question for new ALSA SoC framwork
10:36 < pinchartl> Until next meeting:
10:36 < pinchartl> - Continue paper work
10:36 < pinchartl> - Continue Renesas inside work
10:36 < pinchartl> Issues and Blockers: None
10:36 < pinchartl> morimoto: any comment ?
10:37 < morimoto> no comment
10:37 < pinchartl> (I've noted the BSP team questions, we'll get to them later in the meeting)
10:37 < dammsan> i would like mr morimoto to comment on my small business
10:37 < dammsan> morimoto: any comment ?
10:38 < morimoto> You can tell me very detail :)
10:38 < morimoto> Ahh, OK, OK, no more.
10:38 < pinchartl> * Niklas
10:38 < pinchartl> Since last meeting:
10:38 < pinchartl> - [PATCH] i2c: adv748x: afe: fix sparse warning
10:38 < pinchartl> - Addressed all VIN v10 review comments.
10:38 < pinchartl> - Patch review
10:38 < pinchartl> - Mini vacation
10:38 < pinchartl> Until next meeting:
10:38 < pinchartl> - Run more tests on VIN v11 and post it.
10:38 < pinchartl> - Start pro-active work on removing single capture mode from VIN
10:38 < pinchartl> - Attend ELC
10:38 < pinchartl> Issues and blockers: None
10:38 < pinchartl> neg: any comment ?
10:39 < neg> No additonal comment
10:39 < pinchartl> thank you
10:39 < pinchartl> * Ulrich
10:39 < pinchartl> Since last meeting:
10:39 < pinchartl> - Set up the IGT test environment
10:39 < pinchartl> Until next meeting:
10:39 < pinchartl> - See how well those IGT tests perform for us
10:39 < pinchartl> Issues and Blockers: None
10:39 < pinchartl> uli___: any comment ?
10:39 < uli___> haven't received anything from jinso yet for that igt task
10:39 < pinchartl> nobody has
10:39 < pinchartl> and that's the next topic for this meeting :-)
10:40 < pinchartl> but before that, any additional comment from anyone ?
10:41 < pinchartl> no comment, so
10:41 < pinchartl> Topic 2. Additional Tasks for 2018 Q1/2
10:41 < pinchartl> The following tasks have been accepted by Renesas.
10:41 < pinchartl> - Dynamic BRS/BRU allocation in display pipelines (Kieran, Laurent) 
10:41 < pinchartl> - DU interlaced modes support (Kieran, Laurent) 
10:41 < pinchartl> - Port and Run igt on the DU (Ulrich)  
10:41 < pinchartl> - V3M Eagle display support (Jacopo)
10:41 < pinchartl> - VIN Capture mode update (Niklas)
10:41 < pinchartl> Full descriptions have been sent, we are now waiting for SoWs.
10:41 < pinchartl> dammsan: the ball is in your camp. can you give us a status update ?
10:41 < kbingham> pinchartl: I presume the date for the task prerequisites will be 'in the past' by the time we get contracts?
10:41 < dammsan> i have reviewed the tasks with Renesas side earlier today and am currently submitting tasks
10:42 < pinchartl> kbingham: last time Jinso updated that date
10:42 < dammsan> i took the liberty to get rid of the early test enviroment deliverable milestone
10:42 < pinchartl> thank you :-)
10:42 < pinchartl> dammsan: so no blocker, and we should receive the SoWs soon ?
10:42 < dammsan> i also added acceptance clause as usual
10:42 < dammsan> yep
10:43 < dammsan> jinso will most likely start sending out sows tomorrow
10:44 < pinchartl> thank you
10:45 < pinchartl> any question from anyone regarding the additional tasks ?
10:46 < pinchartl> no question, so
10:46 < pinchartl> Topic 3. BSP Team Requests
10:46 < pinchartl> - VIN driver doesn't seem to have 32bit compatibility
10:46 < pinchartl> There is no .compat_ioctl32 operation defined in the driver.
10:46 < pinchartl> as far as I know, 32-bit compatibility requires drivers to implement a .compat_ioctl32 handler only if they have custom ioctls
10:47 < pinchartl> standard ioctls are handled in the V4L2 core
10:47 < pinchartl> the VIN driver doesn't have any custom ioctl, so I think no action is needed
10:47 < pinchartl> neg: can you confirm that ?
10:47 < pinchartl> morimoto: did the BSP team run into a specific issue, or did they notice it through code analysis only ?
10:48 < neg> pinchartl: I will rerun my test but I'm sure I in the past have tested VIN on ARM64 with a 32 bit user-space without issues
10:48 < morimoto> I'm sorry that I posted it without checking (because I was busy this morning)
10:48 < pinchartl> morimoto: no worries
10:49 < morimoto> But it seems there is no issue on BSP side, this is *just* question
10:49 < pinchartl> ok
10:49 < pinchartl> then we have an answer :-)
10:49 < pinchartl> - vsp-test has many fail on H3 ES1.1 board
10:49 < pinchartl> The following tests failed:
10:49 < pinchartl> - UDS scaling (vsp-unit-test-0003.sh) - CLU/LUT (vsp-unit-test-0010.sh) - Runtime H/V flip (vsp-unit-test-0012.sh) - SRU scaling (vsp-unit-test-0015.sh) - HGT (vsp-unit-test-0023.sh)
10:49 < neg> pinchartl: Only difference is that v4l2-compliance prints an extra log line in console due to how the v4l2 compat layer is implemented, but that might be fixed lately :-)
10:50 < pinchartl> I've checked the logs briefly
10:51 < pinchartl> tests 3 and 15 fail due to a raw2rgbpnm conversion failure in YUV444M
10:51 < pinchartl> tests 10 and 12 fail due to a problem setting controls with yavta
10:51 < pinchartl> test 23 fail for an unknown reason
10:51 < kbingham> pinchartl: I have created a vsp-tests-0000 which reports the test running conditions - might be worth getting that in so that we know what conditions the tests get launched in.
10:52 < kbingham> (which binaries are available etc)
10:52 < pinchartl> at this time I would guess this is all caused by a combination of an incorrect yavta version, possibly an old raw2rgbpnm version, and possibly a wrong shell (the tests have been developed for the busybox ash shell)
10:52 < kbingham> a 'pre-test' test
10:53 < pinchartl> that can be useful too
10:53 < pinchartl> I'll investigate a bit more
10:53 < morimoto> (I thought this is not related to well-known CMA size issue)
10:53 < pinchartl> no it's not
10:53 < kbingham> aha - another pre-test condition to add to my test-0 :D
10:54 < pinchartl> next question
10:54 < pinchartl> - VIN continuous capture mode
10:54 < pinchartl> In the e-mail exchange
10:54 < pinchartl> Subject: [periperi] Question about v4.14 VIN driver transfer mode
10:54 < pinchartl> Date: Fri, 19 Jan 2018 06:22:20 +0000
10:54 < pinchartl> Niklas said
10:54 < pinchartl> "Yes I will do my best to have this done by end of February. I don't see any 
10:54 < pinchartl> blockers to have a patch to fix this by then."
10:54 < pinchartl> the work has since then been turned into an additional task that is scheduled 
10:54 < pinchartl> for 3/M
10:55 < pinchartl> neg: is that correct ?
10:55 < pinchartl> morimoto: is that OK ?
10:56 < morimoto> OK, thanks
10:56 < neg> pinchartl: yes that was my understanding of the situation, sorry if I missunderstood
10:57 < pinchartl> neg: maybe we should have replied to the e-mail thread with the updated schedule
10:57 < pinchartl> but on the other hand I expect information about additional tasks and their schedule to be available within Renesas
10:58 < pinchartl> maybe that's an incorrect assumption
10:58 < neg> pinchartl: yes I agree, my bad the more information that is shared the better and I can contribute to that by replying to emails that is a good thing :-)
10:59 < pinchartl> neg: no worries
10:59 < pinchartl> morimoto: any other question from the BSP team ?
10:59 < morimoto> 1 small qestion
11:00 < morimoto> They want to use 4K with HDMI on Salvator-X(S)
11:00 < morimoto> But it doesn't work
11:00 < morimoto> do you have some plan for it ?
11:00 < pinchartl> not at the moment. we can schedule work for that for next quarter
11:00 < pinchartl> what is the issue, is there more information ?
11:00 < morimoto> Is it big work ? or easy work ?
11:01  * kbingham suspects his 4k TV is going to get moved....
11:01 < kbingham> (or the -XS could move to the living room)
11:01 < pinchartl> morimoto: no idea, we need to research it first
11:01 < morimoto> OK
11:01 < morimoto> the background is
11:01 < morimoto> BSP + StarterKid works for 4K, they said, but upstream isn't
11:02 < morimoto> I know BSP have some local patch
11:02 < morimoto> so this is just question
11:03 < pinchartl> we can research that and fix it
11:03 < morimoto> Thank you !
11:03 < morimoto> not hi priority, no stress
11:04 < pinchartl> what is starterkid ?
11:04 < pinchartl> starter kit ? :-)
11:04 < kbingham> pinchartl: Hugo :)
11:04 < morimoto> oops, yes kit, it is ULCB
11:04 < morimoto> Kid is me
11:05 < kbingham> morimoto: Young at heart eh :D
11:05 < pinchartl> :-)
11:05 < morimoto> :)
11:05 < pinchartl> next topic is SW Feedback to HW team for R-Car Gen4
11:05 < pinchartl> but before that
11:05 < pinchartl> while everybody is still here
11:05 < pinchartl> let's schedule the next meeting
11:05 < pinchartl> as I mentioned earlier I'll be on holidays two weeks from now
11:05 < pinchartl> so I won't be able to attend the meeting
11:05 < pinchartl> and neither will Kieran
11:06 < pinchartl> I don't mind though, someone else can host it
11:06 < pinchartl> would that be ok ?
11:06 < kbingham> pinchartl: Nor neg - He'll be in ELC
11:06 < pinchartl> indeed
11:06 < pinchartl> and so will Magnus and Morimoto-san if I'm not mistaken ?
11:06 < neg> kbingham: you type faster then me :-)
11:06 < kbingham> I suspect postponing to the week after is best.
11:06 < kbingham> neg: :D
11:07 < morimoto> I and Magnus go to ELC too
11:07 < pinchartl> geertu: should we postpone by a week ?
11:07 < jmondi> I now need to go for a doctor appointment... I'll read later when next meeting is scheduled and I have no particular feedbacks for Gen4
11:07 < jmondi> sorry about that
11:07 < pinchartl> jmondi: no worries
11:08 < pinchartl> while waiting for Geert to wake up, let's address
11:08 < pinchartl> Topic 4. SW Feedback to HW team for R-Car Gen4
11:08 < pinchartl> * Niklas
11:08 < pinchartl> I find the VIN register VNCSI_IFMD_CSI_CHSEL to problematic and it have 
11:08 < pinchartl> created a lot of extra work in driver development. The VIN instances are 
11:08 < pinchartl> independent of each other and fits rather well with the Linux driver 
11:08 < pinchartl> model in regard to PM and clocks etc.
11:08 < pinchartl> Since the VNCSI_IFMD_CSI_CHSEL are only present on VIN0 and VIN4 but 
11:08 < pinchartl> controls input settings for VIN{1,2,3,5,6,7} this creates a dependency 
11:08 < pinchartl> between the different VIN driver instances. This is annoying and I'm not 
11:08 < pinchartl> sure if this really simplifies the hardware (I'm no hardware engineer)?  
11:08 < pinchartl> As the register selects different inputs for different VINs based on a 
11:08 < pinchartl> single integer value in the CHSEL register each VIN likely still have 
11:08 < pinchartl> its own separate input multiplexing logic?
11:08 < pinchartl> I base this assumption on the presence of the VNMC_DPINE register which 
11:08 < pinchartl> is yet another multiplexing selection bit which is present only in VIN4 
11:08 < pinchartl> and VIN5. This bit controls if the VIN input come from CSI-2 receiver or 
11:08 < pinchartl> form the digital parallel input and this register is local to the VIN 
11:08 < pinchartl> for which the selection is valid.
11:09 < pinchartl> neg: how would you like to see this implemented in Gen4 ?
11:10 < neg> I'm no HW engineer so there might be constraints I'm not aware of but in my mind makig the VNCSI_IFMD_CSI_CHSEL register local to each VIN and independent of each other would be nice if it where possible
11:12 < morimoto> it is almost same as geert's comment ?
11:12 < morimoto> - All device instances should be mappable independently
11:13 < pinchartl> if that can't be done, would moving it to a syscon help ?
11:14 < pinchartl> morimoto: I don't think so. the problem here is that a register field located in one VIN influences all VINs
11:14 < pinchartl> the VINs are still mappable independently
11:14 < neg> I'm not sure how a syscon would look like so I can't awensere that
11:15 < pinchartl> the register would be in a separate register space
11:15 < pinchartl> that would have its own DT node
11:15 < pinchartl> with a phandle pointing to it in all DT nodes
11:15 < pinchartl> s/DT nodes/VIN nodes/
11:16 < neg> Yes I think that would help as a separate DT node and a separate driver would make things easier
11:18 < pinchartl> another issue from me
11:18 < pinchartl> * Laurent
11:18 < pinchartl> Resource sharing in DU and VSP is painful to handle in software.
11:18 < pinchartl> In Gen2 SoCs the DU shared a set of 8 planes per group of two DU channels. This was configured through registers that required both DU channels to be disabled to change the plane assignment. Moving a plane from one DU channel to another caused flicker on the screen as the two channels had to be disabled, even if the plane was disabled to start with (disabled planes were still assigned to one DU channel
11:18 < pinchartl> ).
11:18 < pinchartl> In Gen3 SoCs the problem disappeared as DU channels do not interface to memory directly anymore but go through VSP-D for that purpose. However, on H3 ES2.0, and on M3-N, the VSP-DL instance serves two DU channels (DU0 and DU3), creating a similar issue. The VSP-DL has 5 inputs and two blending units, BRU and BRS. The BRU can blend up to 5 inputs and the BRS up too 2 inputs. The BRU and BRS thus have to
11:18 < pinchartl>  be assigned to the DU channels dynamically at runtime based on the number of inputs used by each channel. As the two DU channels run asynchronously, this requires stopping display on one channel to release the blending unit in use, reconfigure the other channel to use that blending unit, and finally restarting the first channel. This creates flicker on the screen.
11:20 < pinchartl> any comment ?
11:20 < pinchartl> Additionally, on both Gen2 and Gen3 resources shared by two channels in a group are controlled through registers in the first channel of the group. This prevents assigning DU channels from the same group to different guests in a virtualized environment. Furthermore, as VSP-DL serves DU0 and DU3, we can't assign DU0 and DU3 to different guests either, even though they are not in the same group. The DU t
11:20 < pinchartl> hus can't be split between different guests.
11:23 < pinchartl> any other pain point with Gen3 hardware ?
11:23 < pinchartl> morimoto: when is the deadline to submit the list of issues ?
11:24 < kbingham> Having also put thought into the BRU/BRS issue - it certainly is painful ...
11:24 < morimoto> I think end of April or May
11:24 < morimoto> I will forward these to HW guys
11:25 < morimoto> But, there is no guarantee to fixed, we are sorry m(_ _)m
11:25 < pinchartl> of course
11:25 < pinchartl> I'll include this in the meeting report
11:25 < pinchartl> we can then think about the other issues until end of March
11:25 < morimoto> Thanks, it is usefl
11:25 < morimoto> useful
11:25 < pinchartl> and compile a report with all the reported issues
11:25 < pinchartl> in order to submit everything together to the hardware team
11:25 < pinchartl> is that OK ?
11:26 < morimoto> Yes, I think so
11:27 < morimoto> "end of March" mean you will busy after skiing :)
11:27 < pinchartl> I'm always busy :-)
11:27 < morimoto> you can do it on lift
11:27 < pinchartl> I'd like to revisit this topic during the next meeting
11:28 < pinchartl> neg: can I rephrase your second paragraph as
11:28 < pinchartl> Since the VNCSI_IFMD_CSI_CHSEL are only present on VIN0 and VIN4 but controls input settings for VIN{1,2,3,5,6,7} this creates a dependency between the different VIN driver instances. This is annoying from a driver point of view, and it would be easier if each VIN had a CHSEL register that controlled its own input routing.
11:28 < neg> pinchartl: thank you
11:29 < pinchartl> ok, that's it for today
11:30 < pinchartl> any last comment ?
11:30 < pinchartl> still no word from Geert for the next meeting
11:30 < pinchartl> I'll propose having it in 3 weeks
11:31 < pinchartl> no more comment, meeting adjourned
11:31 < pinchartl> thank you all for attending