Core-chat-meeting-2016-01-06 10:03 < geertu> Today's Agenda: 10:03 < geertu> 1. Upcoming Gen3 development for the Core group, 10:03 < geertu> 2. Status check for tasks from last meeting - what is remaining? 10:03 < geertu> Topic 1. Upcoming Gen3 development for the Core group 10:04 < dammsan> i'm working on the IPMMU 10:04 < dammsan> i've updated the boot loader and 4GiB of RAM is supposed to be available 10:05 < geertu> "supposed to be" 10:05 < dammsan> need to test that, and try to use IPMMU with the DU/VSP 10:05 < dammsan> i'd like to sync the boot loader update with other people as well 10:05 < pinchartl> dammsan: I was going to mention that 10:06 < dammsan> morimoto: shimoda: how can we share boot loader binaries with all the members? 10:06 < pinchartl> should we make sure we all use the same bootloader ? 10:06 < dammsan> i think so 10:06 < pinchartl> or should we make sure we test our kernel on a variety of bootloaders ? 10:06 < geertu> Both are valuable options 10:06 < dammsan> there are too many combos 10:06 < morimoto> dammsan: do you mean export problem ? 10:06 < dammsan> if you mix and match 10:07 < dammsan> morimoto: that could be some issue. i was more thinking of how to provide the information 10:07 < geertu> We mix toolchains, kernel configs, userland, ... too 10:07 < dammsan> morimoto: is it under NDA? 10:07 < dammsan> geertu: that is true 10:08 < pinchartl> I believe it depends on whether we can expect customers to use a recent boot loader 10:08 < morimoto> dammsan: it is difficult question... 10:08 < geertu> The bad thing (compared to toolchains, kernel configs, userland) is that the firmware is a black box 10:08 < pinchartl> there's no point in testing a boot loader that is not used 10:08 < dammsan> table.txt describes six different components at this point 10:08 < dammsan> just to get to u-boot 10:09 < dammsan> i recommend using complete releases, instead of mixing and matching 10:09 < dammsan> morimoto: can you ask ito-san about how to share boot loader stuff? 10:09 < morimoto> dammsan: OK but tomorrow 10:09 < dammsan> morimoto: i think other guys like baylibre also need new boot loader 10:09 < dammsan> sure 10:10 < dammsan> maybe we can have boot loader upgrade fest at peripericon 10:10 < dammsan> anyway, i'm poking around with those things 10:10 < dammsan> other people? 10:11 < neg> working on SYS-DMAC, making slow progress :) 10:11 < dammsan> neg: i can share my older gen2 bits with you 10:11 < dammsan> not sure if i made them public 10:12 < dammsan> i probably did 10:12 < neg> '[PATCH] ARM: shmobile: IPMMU and DMAC prototype' ? 10:12 < pinchartl> dammsan: table.txt ? do you mean table.html ? 10:13 < geertu> dammsan: How many boards will survive the boot loader upgrade and capacitor soldering fest? ;-) 10:13 < dammsan> neg: need to look into detail, lets chat more later after this meeting 10:13 < neg> geertu: did you evere here back from Vinod Koul for on '[PATCH] dmaengine: use phys_addr_t for slave configuration' ? 10:13 < neg> dammsan: ok 10:13 < geertu> neg: 2015-12-15: "I should be able to do this in next few days... 10:14 < geertu> " 10:14 < dammsan> pinchartl: table.txt is from SCIF D/L mode boot loader update script sent yesterday 10:14 < dammsan> geertu: prediction - zero =) 10:14 < pinchartl> dammsan: ah ok 10:15 < shimoda> about boot loader, yocto team releases it at github, but it is a few old 10:15 < shimoda> https://github.com/renesas-rcar/meta-renesas/tree/fido/meta-rcar-gen3/recipes-bsp 10:15 < geertu> How many of these 6 parts contain GPLed code? 10:18 < pinchartl> I see 3 boot loaders, one (un)trusted OS, a certificate and boot parameters 10:19 < pinchartl> do we know how the pieces fit together exactly ? 10:20 < pinchartl> it looks like source code is available for everything but the boot parameters and the certificate 10:20 -!- shimoda [~shimoda@relprex1.renesas.com] has quit [Ping timeout: 240 seconds] 10:20 -!- morimoto [~user@relprex1.renesas.com] has quit [Ping timeout: 260 seconds] 10:21 < pinchartl> will dammsan be next ? 10:21 < dammsan> shimoda: indeed looks a bit old 10:21 < dammsan> geertu: fortunately i don't have to look inside the box 10:22 < dammsan> if you find something fishy let us know and we will try to improve the situation 10:22 < dammsan> neg: i sent you my more recent gen2 experiment via email 10:23 < dammsan> pinchartl: you only have to care about running the script that i sent you 10:23 < neg> dammsan: thanks 10:23 < dammsan> good thing is that the SoC has Mask ROM SCIF D/L support so it is difficult to brick 10:23 < pinchartl> dammsan: with the binaries 10:24 < pinchartl> difficult or impossible ? :-) 10:24 < dammsan> pinchartl: if you have time then i can think of many more important things to do =) 10:24 < pinchartl> :-) 10:25 < dammsan> pinchartl: i build my own u-boot and omitted some secure code when i received the board during summer vacation 10:25 < dammsan> but there is enough bugs as-is without trying to poke around 10:25 < dammsan> for instance, to get IPMMU working update is needed 10:25 < dammsan> i am also pretty sure that SMP will need more work 10:26 < pinchartl> do we need to update before february ? 10:26 < dammsan> anyway, i think we should consider upgrading rather soon 10:27 < dammsan> so we can enable more memory upstream 10:27 < pinchartl> ok 10:27 < dammsan> lets see what morimoto-san and shimoda-san says 10:27 < dammsan> what are other people hacking on? 10:28 < geertu> I want to look into SYSC PM Domains and integrate it with your DT CPU bringup series 10:28 < dammsan> cool 10:29 < dammsan> when i hear PM i am also thinking of making sure Suspend-to-RAM works 10:29 < dammsan> ideally i wanted to get that going before enabling SMP 10:29 < geertu> SMP is already enabled ;-) 10:30 < geertu> And I want to fix suspend with CONFIG_DEBUG_RODATA=y 10:30 < dammsan> yeah, so now we need to consider SMP as well 10:30 < dammsan> which drags in the boot loader dependency 10:30 < dammsan> geertu: we were talking about SCIF hardening with DMAC 10:31 < dammsan> part of DMAC enablement i guess 10:31 < geertu> "ARM: mm: flip priority of CONFIG_DEBUG_RODATA" revealed a big in the shmobile asm suspend code. The patch was reverted, but will come back in next merge window 10:31 < geertu> Yeah, another thing I plan to do 10:32 < geertu> s/big/bug/ 10:32 < dammsan> geertu: may i ask about ordering 10:32 < dammsan> with SYS-DMAC enablement and also PM 10:32 < geertu> Sure 10:32 < geertu> What's your preferred order? 10:32 < dammsan> does it make sense to enable some initial support before updating the boot loader? 10:33 < dammsan> geertu: did SMP work for you or not - i don't remember 10:33 < geertu> Yes, SMP works (all 8 cores) 10:33 < geertu> If it doesn't work, try SW10 10:33 < dammsan> good! 10:33 < dammsan> i've spent quite some time with SW10 updating boot loaders thanks =) 10:34 < dammsan> so i guess enabling DMAC is a rather good activity 10:34 < dammsan> doing that this month, does that make sense? 10:35 < geertu> Sure 10:35 < dammsan> and later on roll in IPMMU 10:35 < dammsan> how about the PM bits 10:35 < dammsan> doing Suspend-to-RAM before or after or parallel? 10:36 < dammsan> i think the timer needs some work too 10:36 < geertu> after / parallel (if the other becomes blocked)? 10:37 < dammsan> sounds good 10:37 < dammsan> it would be neat to get kexec working too 10:37 < geertu> Is it working now on arm64 in general? 10:37 < dammsan> i would assume no 10:38 < dammsan> so geertu: for SCIF hardening and DMAC enablement, what is needed apart from DTS? 10:39 < dammsan> i saw your recent BRG patches, shall Mbps setting over loopback work? 10:39 < geertu> It should 10:40 < dammsan> great!! 10:40 < geertu> dammsan: Fixing the hardware (perhaps)? 10:40 < dammsan> obviously with b0rk timer nothing works well 10:41 < dammsan> geertu: what pending issue are you thinking of? 10:41 < geertu> last time I tried, RX SCIF DMA didn't work at all 10:41 < geertu> (Yes, I have to retry) 10:41 < geertu> on r8a7795 10:42 < dammsan> geertu: maybe we can revisit after data sheet update and boot loader update 10:42 < dammsan> how about other people? 10:43 < dammsan> pinchartl: you were proposing to conver the IOMMU driver to be more modern for ARM32? =) 10:43 < geertu> dammsan: Speaking about datasheet update, I have to look into the recent errata for CPG 10:43 < pinchartl> dammsan: yes 10:44 < dammsan> geertu: yeah, errata.. also we were talking about keeping the GPIO MSTP bit enabled 10:44 < pinchartl> if we want to use the same IOMMU driver on ARM32 and ARM64 we'll need that 10:45 < dammsan> pinchartl: i was hoping that you could work with neg for the framework bit for IPMMU + DMAC 10:45 < pinchartl> do you mean guiding Niklas or writing the code myself ? :-) 10:45 < dammsan> pinchartl: i was never opposed to that change, but i did not want to block r8a7795 prototype support on that 10:46 < dammsan> pinchartl: how about you work together and figure out the details by yourself? =) 10:46 < pinchartl> I won't have time to do the work in January, but I can guide Niklas 10:46 < dammsan> geertu: what do we have on the todo list that need attention from pinchartl? 10:47 < dammsan> i want renesas-drivers to have working DU VGA-out on Salvator-X 10:47 < dammsan> so i can poke around with IPMMU on top of that 10:48 < pinchartl> that is on my to-do list 10:48 < geertu> dammsan: pinctrl documentation acked-by ;-) 10:48 < dammsan> pinchartl: guiding neg sounds good 10:48 < pinchartl> speaking of DU VGA out 10:48 < pinchartl> that involves the VSP1 10:48 < pinchartl> and thus V4L2 10:48 < geertu> dammsan: a patch fixing the vsp1 BUG() with media-next? 10:48 < pinchartl> I'm not in best terms with the V4L2 maintainer at the moment 10:48 < pinchartl> which could introduce delays in getting patches upstream 10:49 < pinchartl> geertu: that's an open issue 10:49 < pinchartl> media-next is broken 10:49 < dammsan> pinchartl: thats fine 10:49 < pinchartl> and if it comes to the worst I'll nack the pull request to Linus 10:49 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi 10:49 < geertu> shimoda-san: Welcome back! 10:50 < dammsan> pinchartl: we need to have something working for use by ourselves and the BSP team 10:50 < pinchartl> dammsan: internally or upstream ? 10:50 < dammsan> in renesas-drivers to begin with 10:50 < dammsan> upstream too, but i understand it may be difficult to control that timing 10:50 < pinchartl> it's very difficult at the moment 10:50 < geertu> Does vsp1 work with current renesas-drivers (i.e. excl. current media-next)? 10:51 < pinchartl> it should but I haven't updated renesas-drivers for about a month 10:51 < pinchartl> I'll test it 10:51 < dammsan> gpinchartl: please do =) 10:51 < pinchartl> for upstream I'm not sure what I can do 10:52 < pinchartl> neither now nor in the future 10:52 < dammsan> please guide morimoto with HDMI audio 10:52 < pinchartl> HDMI audio on Gen3 ? 10:52 < shimoda> geertu: hi :) 10:52 < dammsan> gen2 to begin with 10:52 < pinchartl> that should be fine 10:53 < pinchartl> but isn't this a core meeting, not a multimedia meeting ? :-) 10:53 < dammsan> aright 10:53 < pinchartl> I'm fine discussing multimedia 10:53 < pinchartl> but we have a multimedia meeting tomorrow 10:53 < pinchartl> I don't want to hijack today's meeting 10:53 < dammsan> yes lets do that then 10:53 < dammsan> but i need to make sure we can consume your stuff 10:53 < dammsan> and it goes through geerts tree 10:54 < dammsan> DU+VSP is starting to become a bottleneck 10:54 < dammsan> thanks for looking into that 10:54 < pinchartl> I'll make sure it works with renesas-drivers excluding media-next 10:54 < geertu> git rerere is my friend 10:54 < dammsan> please work with geert to sort it out 10:54 < pinchartl> but for upstream I have no idea how things will turn out 10:54 < pinchartl> if I nack the media-next pull request my ability to get anything merged in media will be diminished 10:54 < dammsan> pinchartl: please talk with hayama-san about that too 10:55 < geertu> For now I can keep excluding media-next, but as soon as Linus has pulled it, we're in trouble 10:55 < pinchartl> if I don't nack it, all kind of crap will end up in mainline 10:55 < geertu> Good, Linus doesn't like crap 10:56 < pinchartl> Linus knows about this already, I know that Mauro has personally contacted him to complain about me 10:56 < pinchartl> I don't know what the outcome of their discussion was though 10:56 < geertu> oops 10:58 < dammsan> regarding upstream merge, i guess we're waiting for the CPG and integration code to hit mainline? 10:58 < pinchartl> upstream merge of what ? 10:58 < geertu> They're in next 10:58 < dammsan> yeah 10:58 < dammsan> a lot of integration code is built but not yet merged upstream 10:59 < dammsan> not sure if any V4L2 explosion will affect ARM64 merge? 10:59 < pinchartl> dammsan: regarding the upstream merge of what ? 10:59 < dammsan> pinchartl: basic initial soc support 11:00 < pinchartl> ok 11:00 < dammsan> i keep my fingers crossed 11:01 < dammsan> neg: do you have any short term "easy stuff" on your todo? 11:01 < dammsan> you may be busy with what you have, but if you need something simple to switch to then please check with geert 11:01 < neg> will do thanks 11:02 < pinchartl> by the way, this is off-topic fore core, but if anyone has advices regarding nacking the media-next pull request vs. not doing it and resigning from V4L2 development, I'll be happy to hear them. we can discuss that later 11:02 < dammsan> i suggest expressing your disagrement lightly in a public space and then take some vacation 11:03 < dammsan> vacation is underrated 11:04 < pinchartl> I wish I could take vacations now :-) 11:05 < dammsan> speaking of which, we need to find some sight seeing spot for peripericon and the nice weather 11:06 < dammsan> pinchartl: let me know how i can help you 11:06 < geertu> FOSDEM is the coldest period of the year in Belgium 11:06 < geertu> Still hot for the Finnish 11:06 < pinchartl> dammsan: if I know how you could, I'd have asked you already :-) 11:09 < dammsan> geertu: we can perhaps browse the local town 11:10 < dammsan> while wearing snow board gear 11:10 < geertu> http://www.oudemarktleuven.be/ 11:10 < geertu> Longest bar in the world ;-) 11:11 < geertu> Any other Upcoming Gen3 development for the Core group? 11:12 < dammsan> geertu: you cant go wrong with that 11:13 < dammsan> geertu: maybe not development, but did anyone plan on building loopback adapters following my plan (or something else?) 11:13 < dammsan> i wanted to do MSIOF loopback but that did not work, need to redo on Gen2 for testing purpose 11:13 < geertu> MSIOF is broken on Gen3 11:14 < geertu> All my (3) adapters are in-use on Koelsch 11:14 < geertu> Will try your setup for SCIF DMA on Salvator-X 11:15 < dammsan> neg: my plan is to give you a break out adapter at peripericon 11:16 < dammsan> geertu: sounds good 11:16 < dammsan> pinchartl: just one final note about IPMMU on Gen3 - some errata exists so i need to keep on doing prototype code with workaround 11:17 < neg> nice, break out adapter for what interface? 11:17 < dammsan> a general purpose thing located by geert, you can use it for many different things 11:17 < dammsan> for instance serial port loopback 11:17 < pinchartl> dammsan: other than the errata I've already received ? 11:17 < neg> ahh ok 11:17 < dammsan> geertu: can you look into using the DT overlays then? 11:18 < dammsan> pinchartl: there is no public information available yet 11:18 < geertu> dammsan: Sure, using overlays all over the place 11:18 < dammsan> or even closed one 11:18 < geertu> dammsan: topic/overlays and topic/renesas/overlays 11:18 < dammsan> geertu: great 11:18 < dammsan> so expect slow IPMMU progress 11:19 < dammsan> thats all from my side 11:19 < geertu> neg: http://www.zebax.com/doc/ZX1/ZX145QTE-020.pdf 11:19 < pinchartl> dammsan: I have received 11:19 < pinchartl> R-CarGen3_HardWare_Manual_Errata_for_Rev050_Oct_31.xlsx 11:19 < pinchartl> R-CarGen3_HardWare_Manual_Errata_for_Rev050_Nov_30.xlsx 11:19 < pinchartl> R-CarGen3_HardWare_Manual_Errata_for_Rev050_Dec_31.xlsx 11:19 * geertu too 11:21 < shimoda> oops, I also have Aug and Sep versions, so I will send them to you later via jinso 11:21 < pinchartl> shimoda: thank you 11:21 < geertu> Would be great, thanks! 11:25 < geertu> Topic 2. Status check for tasks from last meeting - what is remaining? 11:25 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list 11:25 < geertu> Is Simon still in the US? 11:25 < dammsan> AU 11:25 < dammsan> i think he arrived in japan on friday 11:25 < dammsan> arrives 11:26 < dammsan> so yes 11:26 < geertu> But still living in a US timezone ;-) 11:26 < dammsan> somehow 11:26 < geertu> I think I have to s/v4.4/v4.6/g and s/v4.5/v4.6/g? 11:27 < geertu> Except for CPG/MSSR 11:27 < dammsan> most likely 11:29 < geertu> dammsan: What happened to adding renesas,intc-ex-r8a7795 to the driver? 11:30 < dammsan> geertu: nothing yet, IRQC and timers are still on my todo. currently overwhelmed by IPMMU workaround stuff 11:31 < dammsan> geertu: i got as far as cooking up a loop back adapter for IRQ pins, but not yet tested 11:34 < geertu> Anything else? 11:35 < dammsan> not from me 11:35 < geertu> For next meeting, I propose Tuesday, January 19, 18h00-19h30 JST / 10h00-11h30 CET 11:36 < pinchartl> geertu: I'll be away that week 11:36 < pinchartl> (on vacation actually, but with e-mail access) 11:36 < shimoda> I'm OK at 19th 11:37 < geertu> pinchartl: Probably we can do without you for once? 11:37 < pinchartl> geertu: you've managed so far, so I think you'll be fine :-) 11:37 < geertu> I'd like not to postpone by one week, as two weeks later we have PeriPeriCon anyway 11:38 < dammsan> 19th sounds good 11:38 < uli___> same here 11:38 < neg> works for me 11:39 < pinchartl> geertu: no worries at all 11:39 < pinchartl> I wasn't asking you to postpone :-) 11:40 < geertu> I just wanted to make you feel more important ;-) 11:40 < pinchartl> :-) 11:40 < dammsan> i think the renesas network is down, but we can assume shimoda-san and morimoto-san are ok 11:41 < geertu> I do see Shimoda-san talking... 11:41 < shimoda> I'm here :) 11:42 < shimoda> however, Morimoto-san already went to home 11:42 < dammsan> geertu: good - that makes one of us 11:42 < dammsan> or two when i look a bit closer 11:43 < geertu> OK, Time to go home ;-) 11:44 < geertu> Thanks for joining