path: root/wiki/Chat_log/20161108-core-chatlog

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