Core-chat-meeting-2016-11-08 09:07 < geertu> Welcome to today's Core Group Chat 09:07 < geertu> ... and try to keep it short ;-) 09:07 < geertu> Agenda: 09:07 < geertu> 1. Status updates 09:07 < geertu> 2. Inquiries from Tokyo 09:08 < geertu> Topic 1. Status updates 09:08 < geertu> First is Simon 09:08 < horms> TODO Update is NULL for me 09:08 < horms> Status: 09:08 < horms> A) What have I done since last time 09:08 < horms> * No core tasks at this time 09:08 < horms> B) What I plan to do till next time 09:08 < horms> * Land Geert's RST patches in reness tree 09:08 < horms> C) Problems I have currently 09:08 < horms> * 16Mbyte kernels: Do we have a timeframe for firmware upgrade? 09:08 < horms> * Gen2 Suspend 2 Ram: What are the next steps (same as last time) 09:08 < horms> * Access to [MH]ULCB documentation and hw 09:08 < horms> -- end -- 09:08 < geertu> s/Gen2/Gen3/? 09:09 < geertu> 16Mbyte kernels: any takers? 09:09 < horms> Same error as last time; yes, gen3 09:09 < horms> Probably Khiem or Shimoda-san are the best bet there 09:10 < shimoda> about 16Mbyte kernel, coming soon 09:10 < horms> superb 09:11 < shimoda> https://github.com/renesas-rcar/u-boot/commits/v2015.04/rcar-3.4.x 09:11 < shimoda> https://github.com/renesas-rcar/arm-trusted-firmware/commit/c2f9fc9f1324d429decd2b2810fd0c0bde577fd7 09:11 < shimoda> they seem -rc 09:12 < shimoda> but 09:12 < horms> Ok, so we might see this by the end of the year? 09:12 < shimoda> horms: yes. perhaps -rc is removed in end of this month I guess 09:12 < horms> ok, great. thanks for the update 09:13 < geertu> Shimoda: Does that firmware enable Lossy Decomp? 09:14 < shimoda> geertu: this should be counfigureble 09:14 < shimoda> so we can disable it 09:14 < morimoto> Basically, Lossy will be enable if we selected MultiMedia package on Yocto 09:14 < morimoto> And I don't select it :P 09:14 < geertu> OK 09:16 < geertu> Suspend 2 Ram: I guess we should try Suspend to Idle? 09:16 < geertu> https://www.linaro.org/blog/suspend-to-idle/ 09:16 < geertu> See also Laurent's write-up of his discussion about this topic at LPC 09:16 < horms> ok, i saw pinchartl's email 09:18 < geertu> Access to [MH]ULCB documentation and hw: Morimoto-san? 09:18 < geertu> H3ULCB docs we already have 09:19 < horms> ok, i seem to be missing them for some reason 09:19 < horms> but not to worry 09:19 < morimoto> ulcb hw access will be remote 09:19 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/H3_ULCB 09:21 < horms> thanks 09:21 < geertu> Morimoto-san: Can we have docs for M3ULCB, too? 09:21 < morimoto> No, at this point 09:21 < morimoto> but will send to you ASAP 09:22 < horms> thanks 09:22 < geertu> thx 09:22 < geertu> Next is Shimoda-san 09:23 < shimoda> a) wrote Lossy infor in eLinux 09:23 < shimoda> b) and c) nothing core tasks to me 09:23 < shimoda> -- end -- 09:23 < geertu> Thanks, Shimoda-san 09:23 < geertu> Next is Niklas 09:24 < neg> A) 09:24 < neg> - Fixed review comments on H3 PFC drive-strengh 09:24 < neg> - PFC fixups in regard to bias handling 09:24 < neg> - Started to work on drive-strength and bias handling for r8a7796 09:24 < neg> B) 09:24 < neg> - Finish r8a7796 PFC work 09:24 < neg> - Send v2 of PFC bias fixups 09:24 < neg> C) None 09:24 < neg> EOT 09:25 < geertu> Thanks Niklas 09:25 < geertu> Next is Morimoto-san 09:25 < morimoto> geertu: (There is no difference between H3/M3 ulcb board. The difference is only SoC) 09:25 < morimoto> A) What I have done since last time 09:25 < morimoto> I'm preparing board export paper work for new guys 09:25 < morimoto> B) What I plan to do till next time 09:25 < morimoto> No Core task 09:26 < morimoto> C) Problems I have currently 09:26 < morimoto> Our team's server HDD has gone (= not relateed to PeriPeri :) 09:26 < morimoto> 09:26 < morimoto> please ignore C) 09:26 < geertu> morimoto: Thanks for confirming (we already assumed that was the case ;-) 09:26 < horms> did someone leave the HDD on the bus? 09:26 < geertu> I hope there using LVM-CRYPT 09:26 < morimoto> This HDD is very local server :) no problem 09:27 < horms> :) 09:27 < geertu> s/there/they're/ 09:27 < geertu> Thanks Morimoto-san 09:27 < geertu> Next is Geert 09:27 < geertu> A) What have I done since last time 09:28 < geertu> - Sent out v2 of SoC identifaction and ESx.y handling 09:28 < geertu> - Waiting for response from Arnd to create shared branch with 09:28 < geertu> soc_device_match() 09:28 < geertu> - Sent out v1 of 64-bit memory with M3-W Ethernet 09:28 < geertu> - 64-bit memory is silently enabled and already working 09:28 < geertu> - Added swiotlb=nobounce to debug 09:28 < geertu> - SYS-DMAC needs 40-bit DMA mask => works 09:28 < geertu> - RAVB DMAC supports 32-bit memory only, needs IPMMU => works 09:28 < geertu> initially, then fails 09:28 < geertu> - Sent clock and pinctrl pull requests for v4.10 09:28 < geertu> B) What I plan to do till next time 09:28 < geertu> - Get SoC identifaction and ESx.y handling accepted 09:28 < geertu> - Queue up RZ/G1M and RZ/G1E clock drivers 09:28 < geertu> - Coerce Simon into taking all MODEMR related patches 09:28 < geertu> C) Problems I have currently 09:28 < geertu> - Too many dependencies between patches and patch series 09:28 < geertu> (but it's getting better, slowly) 09:28 < geertu> --- EOT --- 09:29 < horms> geertu: let me know if/when/how i cn help with C) 09:29 < geertu> So IPMMU for RAVB seems to work a bit. 09:29 < geertu> Unfortunately the IPMMU expert is missing (JP lessons?) 09:30 < geertu> As Uli, Magnus, Laurent, and Khiem are missing, Topic 1 is finished 09:30 < geertu> Topic 2. Inquiries from Tokyo 09:30 < geertu> A) H3 PFC from BSP team. 09:30 < geertu> Some definitions will be conflict between H3 ES1.x and ES2.0 09:30 < geertu> BSP team would like to know how to handle this (if we use single pfc-r8a7795.c). 09:31 < geertu> IIUC, H3 ES2.0 PFC is almost identical to M3-W PFC. 09:31 < geertu> So can't we use pfc-r8a7796.c for both (with some runtime table patching)? 09:33 < morimoto> And I got 2 request from BSP team for renesas-drivers + v4.9 09:33 < morimoto> 1) HDMI out plan (= Geert ?) 09:33 < morimoto> 2) m3ulcb plan (= Simon ?) 09:33 < morimoto> 09:33 < geertu> Any comments on H3 ES2 PFC? 09:34 < geertu> Does it make sense? 09:35 < geertu> 1) HDMI out plan 09:35 < neg> I think so, so far I have only discoverd veary small diffs when looking at drive-strength and bias settings 09:35 < morimoto> geertu: Does this "runtime table patching" means compatible with "-esxx" ? 09:35 < shimoda> geertu: thank you for the comment about the PFC 09:35 < geertu> Isn't this something for MultiMedia? If I receive a pull request, I can include it 09:36 < shimoda> BSP team are also think about it (use pfc-r8a7796 or separate files for es1.x and es2.0) 09:36 < horms> 2) m3ulcb plan 09:36 < geertu> No, soc_device_match(r8a7795es1) 09:36 < horms> I merged most of the patches from Vladimir yesterday 09:36 < geertu> Cfr. "[RFC] pinctrl: sh-pfc: r8a7795: Add PoC support for R-Car H3 ES2.0" 09:36 < horms> so they should appear in renesas-drivers soon 09:37 < horms> I did not merge the SDHI enablement patches but I expect to do so soon as the update requested is small at this time 09:37 < morimoto> geertu: Ahh OK. make sense. But can use "-esxx" compatible too, right ? 09:38 < morimoto> horms: thanks ! 09:38 < geertu> morimoto: yes, we could use renesas,pfc-r8a7795-es2 too, as we need a separate DTS anyway 09:39 < geertu> Recently Mark Rutland said: 09:39 < geertu> "If it affects the programming model 09:39 < geertu> of the device, it should be described in the compatible string, or in 09:39 < geertu> properties on the device node." 09:40 < horms> what does "programming model" mean? 09:40 < geertu> But we can't add renesas,pfc-r8a7795-es1 retroactively 09:40 < geertu> = how you talk to the module 09:41 < geertu> For CPG/MSSR the differences between ES versios are just additions and removals of registers and bits 09:41 < geertu> for PFC I think it's slightly different, so "different programming model" may apply 09:42 < geertu> warranting a compatible change 09:43 < geertu> Any other comments about PFC? 09:44 < shimoda> sorry i don't understand yet.. 09:44 < geertu> Shimoda: What should I explain better? 09:44 < shimoda> bsp team have concern about the #define 09:45 < shimoda> it will be conflict if we follow the datasheet 09:46 < shimoda> or, any #defines is not useful after boot? 09:48 < shimoda> this means the #define (e.g. IP9_7_4) is for just a programmer? 09:49 < geertu> If we use pfc-r8a7796.c for H3 ES2, the definition of IP9_7_4 is correct, right? 09:49 < shimoda> yes 09:50 < geertu> If the only differeences between H3ES2 and M3-W are differences in pinmux_data[], we can use runtime patching 09:51 < geertu> Of course we can start using a separate pfc-r8a7795-es2.c, and see if/what can be merged with pfc-r8a7796.c later 09:53 < horms> Is it possible to do the reverse with a pfc-r8a7795-es1.c? 09:53 < geertu> Yes we can 09:54 < geertu> But I think pfc-r8a7795-es1.c still has to match against existing renesas,pfc-r8a7795 09:54 < horms> That would seem slighly better in terms of future clean up imho 09:54 < geertu> while new pfc-r8a7795.c would match against new renesas,pfc-r8a7795-es2 09:54 < horms> well, unless its acceptable to make a hard incompatibility 09:54 < geertu> unless we decide the "programming model" doesn't differ, and soc_device_match() is OK 09:55 < geertu> for this purpose 09:55 < horms> yes, i wonder what "programming model" means 09:55 < geertu> "does it work with an unmodified driver" 09:55 < horms> I think that in the long run renesas,pfc-r8a7795 should match what (first) goes into mass production 09:56 < horms> which seems unlikely to be es1 09:57 < geertu> Then we have no choice but to go for soc_device_match() 09:58 < horms> I see your point that using soc_device_match() would make that goal easier 09:58 < horms> goal = using renesas,pfc-r8a7795 with mass production chops 09:58 < horms> well, my goal :^) 09:59 < horms> what do you think is the best way forwards 09:59 < horms> iirc you advocated using soc_device_match() in Berlin but a consensus was not reached in the group 09:59 < geertu> If that is the goal, we have to go for soc_device_match() 10:00 < horms> ok 10:00 < geertu> which is fine for me (the "programming model" is IMHO a gray array for PFC) 10:00 < horms> i think we need to continue this discussion with Magnus in the room as I'm sure he has an opinion on this 10:01 < horms> tbh i'm kind of disturbed if Mark Rutland is setting policy we have to follow 10:01 < horms> but if its grey then i have few complaints 10:01 < geertu> This is not really a new policy 10:01 < horms> ok, he was just stating the existing best practice? 10:02 < shimoda> I have a question for ES2.0 support of PFC 10:02 < shimoda> RFC patch of pfc-r8a7795.c said 10:02 < shimoda> } else { 10:02 < shimoda> pr_info("%s: R-Car H3 >= ES2.0\n", __func__); 10:02 < shimoda> // FIXME Fixup r8a7795_pinmux_info for ES2.0 10:02 < shimoda> } 10:03 < shimoda> what will be appear at FIXME line? 10:03 < shimoda> i cannot image it yet.. 10:03 < geertu> Code to modify struct sh_pfc_soc_info r8a7795_pinmux_info 10:04 < geertu> e.g. to point to the r8a7796 tables instead, and patch them where needed 10:06 < geertu> Does that explanation help? 10:06 < shimoda> i see. the r8a7796 tables is in pfc-r8a7796.c? or copy & paste it into pfc-r8a7795.c? 10:06 -!- horms2 [~horms@217.111.208.18] has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org] 10:07 < geertu> shimoda: The r8a7796 tables are indeed in pfc-r8a7796.c 10:07 < geertu> If we start with separate full tables, the code would make r8a7795_pinmux_info point either to the ES1.x or the ES2 tables 10:09 < shimoda> i got it. for now some tables are "static". so should we modify the "static" for it? 10:10 < geertu> If needed, we ahve to drop the static and/or const 10:10 < shimoda> Thank you! I understood it! 10:11 < geertu> Good. 10:11 < geertu> Anyone who's also in MultiMedia who knows about "HDMI out" state? 10:12 < morimoto> Maybe Ulich 10:13 < horms> morimoto: maybe he is absent 10:14 < morimoto> He has such additional task I think (prototype) 10:14 < morimoto> After that Laurent will work for upstreaming 10:15 < neg> I got some reports from Fukawa-san at Renesas who was testing VIN+DU on both VGA and HDMI out on H3 (i think) so something seems to work 10:17 < geertu> So it's WIP 10:18 < geertu> If it's working, I can add it to renesas-drivers 10:18 < pinchartl> geertu: the plane was late, I'm in the train back home, and my luggage is sill in JFK 10:18 < geertu> pinchartl: Oops 10:19 < horms> at least you arrived on the scheduled day :) 10:19 < geertu> pinchartl: The crew had to vote first? ;-) 10:19 < pinchartl> please proceed without me today :-) 10:20 < geertu> I think we're almost finished. 10:21 < geertu> Unless someone has something to add (subtract, multiply, divide, ...)? 10:22 < horms> nothing from my side 10:22 < shimoda> nothing from me 10:24 < geertu> Thanks for joining, and have a nice continued day