1 files changed, 124 insertions, 0 deletions
diff --git a/wiki/Chat_log/20170606-core-chatlog b/wiki/Chat_log/20170606-core-chatlog
new file mode 100644
index 0000000..8d5f65f
--- /dev/null
+++ b/wiki/Chat_log/20170606-core-chatlog
@@ -0,0 +1,124 @@
+Core-chat-meeting-2017-06-06
+
+10:02 < geertu> Welcome to today's Core Group Chat!
+10:03 < geertu> Agenda:
+10:03 < geertu> 1. Status updates
+10:03 < geertu> 2. Discussion topics
+10:03 < geertu> Topic 1. Status updates
+10:03 < geertu> A) What have I done since last time
+10:03 < geertu> B) What I plan to do till next time
+10:03 < geertu> C) Problems I have currently
+10:04 < geertu> (tampered with) sort -R said Niklas is first
+10:04 < neg> A) No core task ATM
+10:04 < neg> B) No plane all time will go to multimeda work next two weeks.
+10:04 < neg> C) None
+10:04 < neg> EOT
+10:05 < neg> s/plane/plan/
+10:05 < geertu> Thank you, Niklas
+10:05 < geertu> Next is Marek
+10:05 < Marex> A) ULCB U-Boot support patch (tested on dammsans board remotely by booting u-boot from u-boot) B) Submit the ULCB U-Boot patch mainline C) No ULCB available, need to buy one to test flashing the U-Boot instead of booting U-Boot from U-Boot
+10:06 < Marex> EOT
+10:07 < geertu> I think C is something to discuss with Öpensöurce AB
+10:07 < Marex> geertu: correct, already work in progress
+10:07 < geertu> Thank you Marek.
+10:07 < geertu> Next is Morimoto-san
+10:07 < morimoto> A) = B) = C) = NULL, sir
+10:08 < geertu> Thank you Morimoto-san!
+10:08 < geertu> Next is Mangnus, who is excused.
+10:08 < geertu> Next is Laurent, who is on holidays
+10:08 < geertu> Next is Jacopo
+10:08 < jmondi> A) Add GR-Peach DTS file
+10:09 < jmondi> - still discussing RZ pinctrl, found a possible way forward
+10:09 < jmondi> B) RZ pinctrl
+10:09 < jmondi> C) None
+10:09 < jmondi> -- eof --
+10:09 < geertu> s@RZ@RZ/A1@
+10:10 < jmondi> geertu: yes, RZ/A1
+10:10 < geertu> Thank you Jacopo!
+10:10 < jmondi> some other RZ are not really RZ :p
+10:10 < geertu> Next is Geert
+10:10 < geertu> A) What have I done since last time
+10:11 < geertu>   - Tested H3ULCB with H3 ES2.0
+10:11 < geertu>   - Looked into D3 CPG/MSSR
+10:11 < geertu>   - Made inventory of code under arch/arm/mach-shmobile that still needs DT
+10:11 < geertu>     conversion, and converted that into a list of tasks for
+10:11 < geertu>     peripelist/core/todo
+10:11 < geertu>   - Started looking into suspend/resume for CPG/MSSR and PFC
+10:11 < geertu>       - Issue is complicated because hardware state is not just lost, but
+10:11 < geertu>         also different from hardware state on kernel entry during normal
+10:11 < geertu>         boot.
+10:11 < geertu>         E.g. on normal boot, U-Boot disables several module clocks.
+10:11 < geertu> B) What I plan to do till next time
+10:11 < geertu>   - Test Salvator XS (when it has arrived)
+10:11 < geertu>   - Suspend/resume for CPG/MSSR and PFC
+10:11 < geertu>   - Mark periupport priority < H commits that are in linux-next
+10:11 < geertu> C) Problems I have currently
+10:11 < geertu>   - None
+10:11 < geertu> EOT
+10:12 < geertu> Next is Simon, who is excused
+10:12 < geertu> Next is Shimoda-san
+10:12 < shimoda> A) study R-Car D3 CPG spec. and forwarded it to Geert-san :)
+10:12 < shimoda> B) investigate R-Car D3 CPG things (especially, I should reply Geert-san's email)
+10:12 < shimoda> C) about pause feature in rcar-dmac
+10:12 < shimoda> -- EOT ---
+10:13 < geertu> Thank you Shimoda-san!
+10:13 < geertu> Which brings us to
+10:13 < geertu> Topic 2. Discussion topics
+10:13 < geertu> Shimoda-san?
+10:13 < shimoda> yes
+10:14 < geertu> Please explain your problem
+10:16 < shimoda> problem is that sh-sci and rcar-dmac implementation is unbalance. I'm not sure it is OK or not
+10:17 < geertu> You mean sh-sci calls dmaengine_pause(), while rcar-dmac doesn't implement it?
+10:17 < shimoda> sh-sci driver calls dmaengine_pause() but rcar-dmac doesn't have .device_pause() for now
+10:18 < shimoda> geertu: yes
+10:18 < shimoda> for now, i don't encounter any problem, but this implementation is storange to me
+10:18 < shimoda> s/storange/strange/
+10:19 < shimoda> since we don't have any issue, we can use them as-is though :)
+10:20 < geertu> The sh-sci driver has a workaround for the absence of .pause(), cfr. the commit that introduced the call (e7327c09def48ccfd204025726f11b57a19a9c24)
+10:21 < geertu> But I agree the DMA implementation of sh-sci is far from perfect
+10:22 < geertu> So Magnus suggested to make a test case if .device_pause() is really needed or not?
+10:22 < shimoda> geertu: yes
+10:24 < geertu> Due to the workaround, I think it's not needed now.
+10:26 < geertu> IIRC, dmaengine_pause() can be called in interrupt context, while dmaengine_terminate_all() cannot (but it's possible we still violate that)
+10:26 < shimoda> geertu: "it's" means .device_pause?
+10:26 < geertu> In the mean time, dmaengine_terminate_all() has been deprecated, in gavor of dmaengine_terminate_sync() or dmaengine_terminate_async()
+10:27 < geertu> Yes, I meant .device_pause() is not needed due to the workaround
+10:27 < geertu> s/gavor/favor/
+10:27 < shimoda> oh, i don't know dmaengine_terminate_all has been deprecated
+10:28 < geertu> dmaengine_terminate_async() can be called from interrupt-context, dmaengine_terminate_sync() cannot
+10:28 < shimoda> i see
+10:28 < geertu> Perhaps Niklas has a better understanding of the modern DMA API?
+10:31 < shimoda> about sh-sci point of view, keep the  dmaengine_pause calling is better? or should we revert it?
+10:31 < neg> not much about the pause implementation I only studied the terminate case
+10:33 < geertu> shimoda: The commit that added the pause also added the workaround, so it's better to not revert it
+10:35 < neg> but yes terminate_async() is the new API, and my understanding is that you should call device_synchronize() after that at some point to make sure it did terminate
+10:35 < shimoda> geertu: about workaround patch, there are the followings?
+10:36 < shimoda> 3b96304 serial: sh-sci: Do not terminate DMA engine when race condition occurs
+10:36 < shimoda> 1d3db60 serial: sh-sci: Call dma_async_issue_pending when transaction completes
+10:36 < shimoda> 371cfed serial: sh-sci: Redirect port interrupts to CPU _only_ when DMA stops
+10:36 < geertu> https://patchwork.kernel.org/patch/7289991/ was an attempt to add pause support to rcar-dmac
+10:37 < geertu> shimoda: Those are fixes for different issues
+10:38 < shimoda> geertu: thank you! but the rcar-dmac patch was rejected in upstream, i think
+10:38 < geertu> Indeed, Laurent didn't like it
+10:41 < shimoda> i got it. i will check about Laurent-san's opinion in the patchwork later
+10:41 < geertu> I'll also add a task to look into pause again
+10:43 < shimoda> geertu: thank you for adding it
+10:45 < shimoda> so my concern point is cleared, thank you!
+10:45 < geertu> good to hear that
+10:45 < geertu> Do we have anything else to discuss?
+10:46  * Marex might've found VC6 devkit to buy
+10:46 < shimoda> nothing from me
+10:48 < Marex> geertu: shall I grab the VC6 kit ?
+10:48 < geertu> Marex: I suppose you'll receive a Salvator-XS anytime soon?
+10:48 < Marex> geertu: I will ? :-)
+10:49 < Marex> geertu: anyway, the VC6 kit has RSMA connectors for each output to it's easy to measure the frequency
+10:49 < geertu> morimoto: Has it been shipped to Öpensöurce AB yet?
+10:49 < Marex> geertu: $186 ... hm
+10:50 < geertu> Marex: You forgot to write the driver in Tokyo? ;-)
+10:51 < Marex> geertu: I didn't have hardware access there :'-(
+10:52 < geertu> Marex: too bad
+10:52 < Marex> geertu: still, I feel like grabbing the kit would help also because the i2c is accessible and I can operate it with the clock commander (IDT tool for programming the chip) and I can snoop on the i2c bus to figure out the gaps in the datasheet
+10:52 < geertu> Marex: Please check with Magnus
+10:53 < Marex> geertu: OK
+10:53 < geertu> Then I think we're finished
+10:54 < geertu> Thanks for joining, and have a nice continued day