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

1 files changed, 113 insertions, 0 deletions

diff --git a/wiki/Chat_log/20180712-io-chatlog b/wiki/Chat_log/20180712-io-chatlog
new file mode 100644
index 0000000..01f3694
--- /dev/null
+++ b/wiki/Chat_log/20180712-io-chatlog
@@ -0,0 +1,113 @@
+09:03 < wsa_> welcome :)
+09:03 < wsa_> here is the condensed summary, please double check:
+09:03 < wsa_> A - what have I done since last time
+09:03 < wsa_> ------------------------------------
+09:03 < wsa_> Geert
+09:03 < wsa_> : upported MSIOF DMA completion improvement and fixed SCIF race conditions
+09:03 < wsa_>   during shutdown.
+09:03 < wsa_> Kaneko-san
+09:03 < wsa_> : got PCIE support for M3-W and M3-N merged.
+09:03 < wsa_> Niklas
+09:03 < wsa_> : resent a patch series to improve SDHI tuning, started reworking the BSP
+09:03 < wsa_>   SDHI reset patches, and started looking into DMA max seg size for SDHI.
+09:03 < wsa_> Shimoda-san
+09:03 < wsa_> : added USB3 role switch support, sent a bugfix for the SDHI DMA RX case,
+09:03 < wsa_>   implemented USB support for r8a77990, and investigated a SCIF overrun
+09:03 < wsa_>   issue.
+09:03 < wsa_> Simon
+09:03 < wsa_> : got SDHI HS400 support merged.
+09:03 < wsa_> Ulrich
+09:03 < wsa_> : sent first version of D3 MSIOF support and researched origins of SCIF
+09:03 < wsa_>   REIE handling
+09:03 < wsa_> Wolfram
+09:03 < wsa_> : fixed a problem in and improved R-Car support for I2C bus recovery and
+09:03 < wsa_>   improved wiki documentation for it, sent a new version of the I2C RXDMA
+09:03 < wsa_>   workaround patch, guided the SCCB redesign including needed preparations,
+09:03 < wsa_>   fixed a regression introduced with the I2C fault injector and resent a
+09:03 < wsa_>   new fault injector, and looked into a SDHI DMA mapping problem.
+09:03 < wsa_>   Before that, he attended ALS2018 and held a talk about DMA safe buffers.
+09:03 < wsa_> B - what I want to do until next time
+09:03 < wsa_> -------------------------------------
+09:03 < wsa_> Kaneko-san
+09:03 < wsa_> : wants to upport M3-N SATA and D3 MSIOF.
+09:03 < wsa_> Niklas
+09:03 < wsa_> : wants to post patch for the now started work and continue with
+09:03 < wsa_>   SDHI tuning improvements.
+09:03 < wsa_> Shimoda-san
+09:03 < wsa_> : wants to make a plan for USB role switch on E3 despite the connector
+09:03 < wsa_>   issue, continue with the SCIF issue if needed, add PWM for E3, and
+09:03 < wsa_>   continue to learn QEMU with USB.
+09:03 < wsa_> Simon
+09:03 < wsa_> : wants to work CPG and DTS changes for HS400.
+09:03 < wsa_> Wolfram
+09:03 < wsa_> : wants to merge the I2C recovery and RXDMA work, keep guiding the SCCB
+09:03 < wsa_>   refactoring, review Niklas SDHI patch series, and check if the SDHI
+09:03 < wsa_>   NON_REMOVABLE workaround is still needed.
+09:03 < wsa_> C - problems I currently have
+09:03 < wsa_> -----------------------------
+09:03 < wsa_> Niklas
+09:03 < wsa_> : mentions that figuring SDHI testing slows him down.
+09:03 < wsa_> Shimoda-san
+09:03 < wsa_> : needs more info from the HW team to make renesas_usbhs work again.
+09:03 < wsa_> Wolfram
+09:03 < wsa_> : is so busy with all the other tasks that QEMU development is lagging.
+09:06 < wsa_> I have a question for shimoda about the SCIF issue and if I got the current status right
+09:06 < wsa_> We all did some research about the REIE and TOIE bit and you reported back our findings to the BSP team
+09:06 < wsa_> and we are waiting now if this is enough for them
+09:07 < wsa_> Is this correct or am I forgetting something?
+09:07 < wsa_> Do we need to work more on this?
+09:08 < wsa_> shimoda: ? (let's try the IRC notification thingie)
+09:09 < wsa_> Other than that, IO group is promised an E3 board
+09:09 < neg> Nice
+09:10 < wsa_> Since E3 is mainly DTS enablement which we agreed to be worked on by Kaneko-san, I voted to have it sent to Simon
+09:10 < wsa_> neg: core and M/M will get one, too
+09:10 < wsa_> so he can test the patches
+09:11 < wsa_> horms: is hat okay with you?
+09:11 < horms> sure!
+09:12 < wsa_> nice
+09:12 < shimoda> wsa_: sorry for the delayed. about REIE and TOIE, this is enough for now.
+09:12 < wsa_> shimoda: thanks!
+09:14 < shimoda> by the way, i'd like to get some opinions about SCIF console overrun issue
+09:14 < shimoda> i sent an email at 2018-07-09 pm 2:48 JST
+09:15 < geertu> shimoda: This is input overrun, right?
+09:15 < shimoda> geertu: yes
+09:16 < geertu> I'm afraid that with flow control disable, there's not much we can do.
+09:16 < geertu> s/disable/disabled/
+09:18 < shimoda> geertu: thanks for your opinion! does this mean this is not a bug on the driver?
+09:19 < geertu> shimoda: Well, printing kernel messages on the serial console is known to interfere with normal serial operation.
+09:19 -!- ulih [~Mutter@x2f7fd43.dyn.telefonica.de] has joined #periperi
+09:20 < geertu> To make it perfectly safe without any interference would mean loosing most of its value (kernel messages may not come through)
+09:20  * geertu wonders if ulih is the SCIF expert?
+09:20 < ulih> morning. network outage, using my wife’s iphone
+09:21 < ulih> what is the matter?
+09:21 < geertu> ulih: We were just talking about the SCIF console overrun issue
+09:23 < wsa_> shimoda-san wrote an email about it on  2018-07-09 pm 2:48 JST
+09:23 < wsa_> but geert already mentioned that "kernel messages on the serial console is known to interfere with normal serial operation"
+09:23 < wsa_> and "I'm afraid that with flow control disable, there's not much we can do."
+09:24 < ulih> ok. thanks for filling me in
+09:25 < wsa_> while ulih thinks about it, are there any other topics from your side?
+09:26 < wsa_> I am done with the "bigger" topics
+09:26 < wsa_> details about upporting will be done 1:1 privately
+09:26 < wsa_> vaishali: I really hope to have the SDHI check done this week
+09:27 < geertu> Has anyone tried QEMU+KVM and I/O pass-through (vfio) with a DMA-capable device directly connected to the IPMMU (i.e. not via SYS-DMAC)?
+09:27 < vaishali> wsa_: Thanks. :)
+09:27 < wsa_> but I'd think the other topics do not depend on it, or?
+09:27 < wsa_> geertu: nope
+09:28 < Marex> wsa_: two more PCIe fixes got in
+09:28 < Marex> wsa_: you wanted to ask about the 32bit limitation of the PCIe at some point
+09:28 < dammsan> geertu: i don't see how the guest dma map/unmap operations would affect the host that has the IPMMU driver?
+09:28 < wsa_> Marex: nice
+09:29 < wsa_> Marex: yup, we missed to talk about this in Japan :( Seems we need to do it by email
+09:29 < dammsan> geertu: i have not tried it, but i dismissed it before doig so =)
+09:29 < wsa_> I will do this later
+09:30 < Marex> wsa_: the thread (Re: [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range) died on the 6th of June, sadly
+09:30 < Marex> wsa_: I can poke the thread if you think it makes sense, although I don't have anything to contribute without really digging in
+09:31 < geertu> dammsan: I hoped it would just work out-of-the-box, as IOMMU and pass-through should work on other systems
+09:31 < geertu> Marex: I can assign "ARM64,?,noplan,?,Handle 32-bit DMA limitation (https://patchwork.kernel.org/patch/10416861/)
+09:31 < geertu> " to you with a single vim edit ;-)
+09:32 < geertu> If you're interested
+09:32 < wsa_> geertu: how about I give you the mic and we talk about it in the core meeting? :)
+09:32 < geertu> wsa_: Sounds like a good idea!
+09:32 < wsa_> good!
+09:32 < dammsan> geertu: maybe reproducing a x86-based environment with vfio might bbbe good?
+09:32 < wsa_> thank you all for this meeting!