Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 210 insertions, 0 deletions

diff --git a/wiki/Chat_log/20170117-core-chatlog b/wiki/Chat_log/20170117-core-chatlog
new file mode 100644
index 0000000..5f9794d
--- /dev/null
+++ b/wiki/Chat_log/20170117-core-chatlog
@@ -0,0 +1,210 @@
+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!