diff options
Diffstat (limited to 'wiki/Chat_log/20170117-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20170117-core-chatlog | 210 |
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! |