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

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!