diff options
Diffstat (limited to 'wiki/Chat_log/20180301-mm-chatlog')
| -rw-r--r-- | wiki/Chat_log/20180301-mm-chatlog | 326 |
1 files changed, 326 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180301-mm-chatlog b/wiki/Chat_log/20180301-mm-chatlog new file mode 100644 index 0000000..0c8afdb --- /dev/null +++ b/wiki/Chat_log/20180301-mm-chatlog @@ -0,0 +1,326 @@ +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 |