Core-chat-meeting-2017-01-17 09:05 < geertu> Welcome to today's Core Group Chat! 09:05 < geertu> Agenda: 09:05 < geertu> 1. Status updates 09:05 < geertu> 2. IPMMU 09:05 < geertu> 3. PFC/GPIO entanglement on RZ/A1H 09:06 < geertu> Topic 1. Status updates 09:06 < geertu> A) What have I done since last time 09:06 < geertu> B) What I plan to do till next time 09:06 < geertu> C) Problems I have currently 09:06 < geertu> $(sort -r) says first is Simon 09:06 < horms> --- begin --- 09:06 < horms> a) What have I done? 09:06 < horms> No core tasks 09:06 < horms> b) What do I plan to do next? 09:06 < horms> Address review of compatibility string analysis. 09:06 < horms> c) What problems do I have? 09:06 < horms> None 09:06 < horms> --- end --- 09:07 < geertu> Thank you, Simon! 09:07 < geertu> Next is Shimoda-san 09:07 < shimoda> --- begin --- 09:07 < shimoda> A) What have I done? 09:07 < shimoda> - Make/test a workaround for Gen3 IPMMU issue with Magnus-san. 09:07 < shimoda> B) What do I plan to do next? 09:07 < shimoda> - Continue to test the IPMMU workaround patch on Gen3 and submit it. 09:07 < shimoda> C) What problems do I have? 09:07 < shimoda> - How to start Power Management things again. Maybe I should start it on email? 09:07 < shimoda> --- end --- 09:08 < geertu> I think email is a good way 09:08 < shimoda> geertu: i got it. i will start it by email 09:09 < geertu> Thank you, Shimoda-san 09:09 < geertu> Next is Niklas 09:09 < neg> A) Posted patch to add support for negative divisors to DIV_ROUND_CLOSEST (needed by Gen3 thermal) 09:10 < neg> B) Do more tests on Runtime PM with GPIO interrupts patches and find a new sutable Core task to start work on (or maybe do that at FOSDEM which is after next IRC meeting) 09:10 < neg> C) None 09:10 < neg> EOT 09:10 < geertu> Thank you Niklas 09:10 < geertu> Next is Morimoto-san 09:11 < morimoto> A) = B) = C) = NULL 09:11 < morimoto> EOT 09:11 < geertu> Thank you Morimoto-san 09:11 < geertu> Next is Marek, who I forgot to introduce (sorry about that). Can you please introduce yourself? 09:12 < Marex> Hi, I'm Marek Vasut, I'm new here, I've been doing kernel work for a while though, thank you for having me 09:12 < Marex> A) I sent the R-Car gyroadc driver to IIO list 09:13 < Marex> B) Waiting for potential further feedback or acceptance into linux-iio 09:13 < Marex> C) None 09:13 < Marex> EOT 09:13 < geertu> Thank you Marek, and welcome to the team! 09:14 < geertu> Next is Laurent 09:14 < pinchartl> I'm just lurking :-) 09:15 < geertu> Thank you Laurent ;-) 09:15 -!- horms2 [~horms@52D9BC73.cm-11-1c.dynamic.ziggo.nl] has joined #periperi 09:15 < geertu> Next is Jacopo 09:15 < jmondi> sure! 09:15 < jmondi> A) I sent out v3 of PFC + GPIO for RZ SoC 09:15 < jmondi> B) I already received some feedback on how it would be better to unify those drivers 09:16 < jmondi> C) Still not sure if it is worth continue developing those driver and not start a new pin-based one for all SoCs with an RZ-like PFC 09:16 < jmondi> but I guess we're going to talk about this later, according to the agenda 09:16 < jmondi> EOF 09:17 < geertu> Thank you Jacopo 09:17 -!- horms [~horms@52D9BC73.cm-11-1c.dynamic.ziggo.nl] has quit [Ping timeout: 248 seconds] 09:17 < geertu> Next is Geert 09:17 < geertu> A) What have I done since last time - Xmas and NY holidays - Prepared meeting Friday before FOSDEM - Posted first version of ARM64 DMA attributes - Sent first pull requests for v4.11 for clk and pfc - Started MSTP Reset feature 09:17 < geertu> B) What I plan to do till next time - Continue MSTP Reset feature - Update ARM64 DMA attributes according to review comments 09:17 < geertu> C) Problems I have currently - None 09:17 < geertu> EOF 09:18 < geertu> (doh, bullet alignment didn't come out that well) 09:18 -!- horms [~horms@penelope.horms.nl] has joined #periperi 09:18 -!- horms2 [~horms@52D9BC73.cm-11-1c.dynamic.ziggo.nl] has quit [Client Quit] 09:18 < geertu> Topic 2. IOMMU 09:19 < neg> When I read Shimoda-sans email I started to think my effort to enable IPMMU in DT for dmac0 and dmac1 on Gen2 is a bit premature whit all the hardware issues. Do I understand that correctly? Should pause my work here until we know if there is a hardware fix? 09:20 < shimoda> neg: i think so (wait until a hardware fix) for now 09:21 < neg> shimoda: OK thanks I will do so 09:21 < shimoda> however, i don't know hardware is fixed (especially gen2) 09:22 < shimoda> neg: yes, please wait anyway 09:22 < pinchartl> neg: do you mean Gen3 ? 09:22 < horms> neg: (off topic) regarding gpio interupts. I see one in the BSP for EtherAVB. I plan to try this as I believe it is a dependency for gigabit speed which is a task for me at this time. 09:22 < geertu> Perhaps in RZ/G? Sergei's RZ/G1M is ES3.0 09:23 < geertu> horms: Gigabit speed is already working for me after "ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W" 09:24 < neg> pinchartl: no Gen2, the IPMMU on Gen3 on ES 1.0 I was told did not work for this so I have done most testing on Gen2 09:24 < horms> geertu: yes, I am aware of that. but the BSP has other bits too. Perhaps it makes it more reliable? 09:24 < shimoda> pinchartl: i hope gen3 fixes this issue. but for now hw team doesn't say so. 09:24 < neg> pinchartl: but with Simons tuninge patchset I started to see odd errors so this is why I ask 09:24 < horms> geertu: in any case I plan to resubmit that patch of yours 09:25 < neg> horms: I have posted patches for Runtime PM with GPIO interrupts so if you test please is those :-) 09:26 < horms> neg: thanks, i will look into them 09:26 < geertu> Speaking about tuning, with renesas-devel-20170116-v4.10-rc4 the M3-W boot takes a long time, due to "sh_mobile_sdhi ee140000.sd: timeout waiting for hardware interrupt (CMD12)" 09:26 < pinchartl> neg: sorry for the confusion. I thought only Gen3 had IPMMU hardware issues 09:26 < geertu> pinchartl: ;-) 09:27 < horms> ok, these mmc problem seem to get worse not better :( 09:27 < geertu> "dmaengine: rcar-dmac: Always disable channel 0" 09:27 < horms> which slot is that? 09:27 < horms> eMMC or a card? 09:27 < horms> in case of the latter which card are you using? 09:27 < geertu> sdhi2 09:28 < horms> ok, can you give me some details of the card at some point? 09:28 < horms> that may or may not be a factor 09:28 < geertu> eMMC (no cards present). Same (arm64 defconfig based) kernel doesn't show the issue on H3 09:28 < horms> ok 09:28 < pinchartl> geertu: yes, I know about that one, I meant hardware issues that we have no workaround for at the moment :-) 09:28 < horms> got it 09:29 < geertu> pinchartl: "dmaengine: rcar-dmac: Always disable channel 0" is not upstream 09:30 < geertu> That's it for IPMMU? 09:32 < pinchartl> shimoda: when you say that the hardware team didn't tell about a fix, do you mean that we don't know when it will be fixed, or we don't know whether it will be fixed at all ? 09:32 < shimoda> geertu: about eMMC on salvator-x, we have 2 types (samsung or SMI) 09:34 < shimoda> pinchartl: i meant hw team doens't decide to fix the issue for now. i guess after our customers complint the issue, they will decide it :) 09:35 < pinchartl> shimoda: do they know that the IPMMU is completely unusable ? 09:36 < shimoda> geertu: about eMMC, I'm afraid but I (and board team) don't track which eMMC chip is mounted. would you check it? 09:36 < geertu> shimoda: H3 has BGSD3R 29.1 GiB, M3-W has eMMC 28.8 GiB 09:38 < geertu> Is that sufficient, or should I look at the physical ICs? 09:39 < shimoda> shimoda: I don't think so because they suggest software workaround... 09:40 < shimoda> geertu: thank you, it is enough to me. H3 is samsung, M3 is SMI 09:41 < shimoda> oops. at 17:37:46, this is for pinchartl :) 09:42 < geertu> That's 09:39 here ;-) 09:42 < pinchartl> shimoda: let's try to then make sure that the software workarounds they suggest can't be implemented :-) 09:42 < shimoda> geertu: :) 09:43 < geertu> pinchartl: The workaround is called swiotlb 09:44 < neg> geertu: will not swiotlb kill preformence like there is no tomorrow? 09:45 < shimoda> geertu: yes. almost all drivers are ok, i think. (performance is down though) 09:45 < geertu> neg: It depends. And it's a workaounrd ;) 09:45 < pinchartl> neg: yes it will 09:45 < shimoda> however, sdhi-dmac doesn't have descripter mode, i would like to use IPMMU somehow to improve performance 09:45 < pinchartl> swiotlb is unusable for DU, VSP or VIN 09:46 < geertu> pinchartl: So you need pinned buffers in <4G mem 09:46 < neg> I see, I just noticed swiotlb so have been trying to read up 09:49 < geertu> Time to move on. 09:49 < geertu> Topic 3. PFC/GPIO entanglement on RZ/A1H 09:49 < jmondi> yup... 09:49 < jmondi> so I have prepared a sum-up of the discussions on mailing lists: https://nopaste.me/view/raw/ee7a1180 09:50 < jmondi> I guess the final question, even before deciding if PFC and GPIO should be merged in a single driver is: do we want to continue pushing this group-based implementation for PFC? 09:51 < pinchartl> jmondi: I wouldn't for RZ/A 09:51 < pinchartl> we have to for R-Car, as the hardware has the concept of groups 09:51 < jmondi> I have received many feedbacks (from Chris and Laurent mainly) on how it would be better to start with a new pin-based pinctrl implementation... Of course this has to be planned, so I would like to discuss this with you all... 09:52 < jmondi> pinchartl: sorry, go on please... 09:52 < pinchartl> I'm done :-) 09:53 < geertu> I have two comments 09:53 < geertu> 1) For R-Car, we have to keep on using groups, as Laurent says 09:54 < geertu> 2) I believe RZ/A is low-priority work for us. So going for the full "rz-pfc/ driver infrastructure" may be going to far, for now. 09:54 < geertu> It would be good to have a simple RZ/A driver upstream, though. 09:55 < geertu> If more users show it, that simple driver can be turned into a "rz-pfc/ driver infrastructure" 09:55 < jmondi> geertu: 1) I never wanted to touch the existing code-base for r-car devices :) 09:55 < geertu> (but it needs a different name than "rz", due to RZ/A vs RZ/G vs RZ/T ;-) 09:55 < horms> rza seems useful from my pov 09:56 < geertu> About memory, RZ/A SoCs are available with 3 or 9 MiB of builtin SRAM, and that may be all on some boards. 09:57 < geertu> Cfr. build you own Cortex A9 board with an SoC in QFP package and 5 external components ;-) 09:57 < jmondi> geertu: according to Chris yes, that's why a run-time creation of groups and functions, as pinctrl-single is doing, may be problematic 09:58 < pinchartl> jmondi: do we have to create all groups and functions at init time ? could we create them on-demand, just for the ones referenced in the device tree ? 09:59 < geertu> jmondi: I haven't looked at the RZ/A PFC driver in the BSP yet... 09:59 < jmondi> pinchartl: that's what happens... the (now moved to core) functions to parse the dts and create groups and functions creates groups only for pins configured in the device tree 09:59 < pinchartl> ok 10:00 < pinchartl> how much memory is that ? 10:00 < pinchartl> compared to the memory allocated by the sh-pfc driver ? 10:00 < jmondi> geertu: there are many of them. Chris has a 3.14 one which does not use device tree yet. Some customer ported it to use DTS and the result is the ABI reported in the file I shared 10:01 < geertu> jmondi: OK 10:01 < jmondi> pinchartl: I guess problem here is that it is run-time memory, compared to huge tables that increases the kernel image size 10:01 < geertu> jmondi: About "tweak pinctrl-single to remove hw specificities: not sure what pinctrl-single maintainer think". Usually maintainers are happy to see that happen 10:02 < geertu> jmondi: Well, the run-time tables will be smaller. The static cables can't be freed anyway. 10:02 < jmondi> geertu: that may be an attempt that ends up in nothing though... Before even trying wouldn't it be better to ask Tony/Linus if this is acceptable? 10:04 < pinchartl> jmondi: and I assume the memory-constrained RZ/A use cases use XIP 10:04 < pinchartl> but sh-pfc also allocates memory at runtime 10:04 < pinchartl> it would be useful to check how much 10:04 < pinchartl> I don't think we can reuse the pinctrl-single driver 10:05 < pinchartl> as it is based on the assumption that one pin will be controlled by a single register 10:05 < pinchartl> we can, however, implement a driver that uses a similar concept 10:06 < jmondi> pinchartl: that's why I thought about having a platform-specific part to hook into pinctrl-single: something like "give mode and configuration and I take care of setting register opportunely for my platform" 10:06 < jmondi> but I understand there's a lot of overhead there 10:07 < pinchartl> many options are possible 10:07 < pinchartl> I'd start with a custom driver, to evaluate the memory impact 10:07 < pinchartl> if it's acceptable, then we could try to reuse code from pinctrl-single 10:08 < pinchartl> if it's not, there's no point :-) 10:08 < jmondi> and I must say I would prefer a smaller driver, with maybe some generated tables at least for validation (ie. not all ports support all 8 modes) 10:09 < jmondi> pinchartl: would that custom driver be a (PFC + GPIO) driver in you opinion, right? 10:09 < pinchartl> I think it should be, given how the hardware is architectured 10:10 < jmondi> pinchartl: the interleaved registers thing is a pain :( 10:11 < pinchartl> only if you want one DT node per bank 10:11 < pinchartl> with a single DT node, it's no big deal 10:12 < jmondi> pinchartl: right.. 10:12 < geertu> A simple combined PFC and GPIO driver makes sense 10:14 < jmondi> geertu: not using sh-pfc/, right? 10:14 < geertu> jmondi: Yep 10:14 < geertu> drivers/pinctrl/renesas-rza1.c 10:15 < jmondi> geertu: ok, let me report these feedbacks to Magnus and see how/when I could work on this... 10:16 < geertu> OK. Time to move on? 10:16 < jmondi> also, I am doing this on a remote board, which is a bit painful... are there other boards with RZ/A SoC, as I understood genmai is available in Japan only 10:17 < jmondi> yeah, sorry... go on, I'll sort this out with Magnus 10:17 < geertu> GR-PEACH 10:18 < geertu> It has the internal 10 MiB only though, unlike Genmai 10:18 < geertu> DigiKey says 117 EUR 10:19 < geertu> (and 409 for the LCD panel shield :-( 10:19 < geertu> I believe Wolfram has a Genmai, too 10:19 < jmondi> geertu: thanks! let's see if I can get one... 10:20 < jmondi> without the LCD panel :) 10:20 < geertu> Doh... 10:21 < geertu> Next meeting will be in real life in Brussels, the Friday before FOSDEM 10:22 < geertu> If you haven't already done so, please confirm your (un)attendence by the morning of Wednesday, January 18th. 10:23 < jmondi> geertu: where should we confirm that? Is there a form or a "I'll be there" is enough? 10:24 < geertu> jmondi: Just let me know. The older timers are already on our mailing list. 10:24 < geertu> s/older/old/ 10:24 < geertu> jmondi, marex: I'll talk to you after the meeting, OK? 10:24 < jmondi> geertu: sure! 10:25 < Marex> yes 10:25 < geertu> So that was the final topic, unless someone has anotheer topic to discuss? 10:25 < horms> geertu: shall we add any new faces to the ML? 10:25 < Marex> geertu: just to confirm, I'll be at fosdem 10:30 < morimoto> ... finished ... ? 10:31 < geertu> Yes, finished :-) 10:31 < morimoto> OK, thanks 10:31 < geertu> Thanks for joining, goodbye!