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

1 files changed, 190 insertions, 0 deletions

diff --git a/wiki/Chat_log/20180524-core-chatlog b/wiki/Chat_log/20180524-core-chatlog
new file mode 100644
index 0000000..50e92a7
--- /dev/null
+++ b/wiki/Chat_log/20180524-core-chatlog
@@ -0,0 +1,190 @@
+Core-chat-meeting-2018-05-24
+
+09:31 < geertu> Welcome to today's Core Group Chat!
+09:32 < geertu> Agenda:
+09:32 < geertu> 1. Status Updates
+09:32 < geertu> 2. Discussion Topics
+09:32 < geertu>   a. Should we implement platform_driver.shutdown() on each device
+09:32 < geertu>      driver?
+09:32 < geertu> Topic 1. Status updates
+09:32 < geertu> A) What have we done since last time:
+09:32 < geertu> Kaneko-san posted M3-N thermal support v4.
+09:32 < geertu> Marek worked on Linux (PCIe and DA9063L support, dropped mtdparts from
+09:32 < geertu> DT) and U-Boot (Blanche and I2C DM/DT conversion, PFC cleanups, xHCI
+09:32 < geertu> fixes).
+09:32 < geertu> Morimoto-san is happily hacking periject.
+09:32 < geertu> Niklas added I2C support to M3-N PFC.
+09:32 < geertu> Shimoda-san resubmitted E3 SYSC (incl. ES1.0 workaround), and upported
+09:32 < geertu> E3 PFC and GPIO support.
+09:32 < geertu> Ulrich posted DMAC bindings upports.
+09:32 < geertu> Geert did some Periupport analysis and upporting, sent clk/pfc pull
+09:32 < geertu> requests, assisted Gilad with H3 CryptoCell support, and removed legacy
+09:32 < geertu> SMP fallback for H2 and M2-W.
+09:33 < geertu> B) What we plan to do till next time:
+09:33 < geertu> Kaneko-san will upport M3-N WDT support.
+09:33 < geertu> Marek will handle PCIe suspend/resume for Linux, and automatic mtdparts
+09:33 < geertu> bootargs on U-Boot.
+09:33 < geertu> Morimoto-san will enhance periject based on feedback.
+09:33 < geertu> Niklas will investigate pinctrl problems on V3M.
+09:33 < geertu> Shimoda-san will upport USB2.0 PFC for E3, and pave the way forward
+09:33 < geertu> for IPMMU.
+09:33 < geertu> Ulrich will work on memory size detection for Gen3.
+09:33 < geertu> Geert will review the RZ/N1 clock driver, do more periupport analysis
+09:33 < geertu> and upporting, and handle CPG/MSSR and SYSC errata.
+09:34 < geertu> C) Problems we have currently:
+09:34 < geertu> Morimoto-san wants more periject feedback.
+09:34 < geertu> Anything I missed?
+09:35 < Marex> geertu: I did some gen3 JTAG digging yesterday
+09:35 < Marex> geertu: on S-X, I observe the problem that reset halt doesn't halt the platform, I want to dig deeper at some point
+09:36 < geertu> Marex: Halt is implemented by the BD9571
+09:36 < Marex> this would help me restore U-Boot on those platforms over JTAG, which in turn would be useful for U-Boot CIing
+09:36 < Marex> geertu: reset halt in OpenOCD is what I mean
+09:36 < geertu> Marex: what's is it supposed to do then?
+09:37 < Marex> geertu: reset the CPU core and stop execution at the reset vector
+09:37 < dammsan> could be power domain related
+09:38 < Marex> dammsan: possibly, or it'll need similar funny hack as Gen2 (although I tried that and it didnt immediatelly work)
+09:38 < Marex> like I said, I need to dig deeper
+09:40 < geertu> OK, keep up the good work!
+09:40 < dammsan> Marex: will you be able to look into OpenOCD support while you have physical board access in Tokyo?
+09:40 < dammsan> in case it is applicable
+09:40 < Marex> dammsan: I have physical Gen3 board here :-)
+09:41 < Marex> dammsan: I can look into it now if it's desired
+09:41 < dammsan> actually i was thinking of gen2 more
+09:41 < Marex> dammsan: Gen2 JTAG is fine, Gen3 has this reset issue and isn't upstream
+09:41 < dammsan> fore more complete support
+09:41 < Marex> dammsan: Gen2 is partly upstream, board support is submitted and pending application, will be in OpenOCD 0.11 according to latest intel
+09:42 < dammsan> cool
+09:42 < dammsan> shall i bring e2 silk? =)
+09:42 < Marex> if you want more Gen2 boards in OpenOCD, sure, why not :)
+09:42 < Marex> dammsan: I have E2 silk on my desk and the board support is submitted, hehe
+09:42 < dammsan> alright then i will shut up
+09:42 < dammsan> let me know if you need some board
+09:43 < Marex> http://openocd.zylin.com/#/c/4532/
+09:43 < Marex> dammsan: Silk, Porter, Stout are submitted, just let me know what other board you want in :-)
+09:43 < kbingham> Marex, Did you post the Gen3? Or are you letting thinkfat handle that ?
+09:45 < Marex> kbingham: thinkfat said he will post it, but I'd like to keep an eye on that
+09:45 < Marex> kbingham: plus, there's the reset halt issue which I'd like to have fixed
+09:46 < kbingham> Marex, halt-reset won't affect me as much - as I want to debug running systems - not necesarily boot it :) anyway - topic for another day :D
+09:46 < Marex> kbingham: I mostly want to use that JTAG to start minimon without flipping the MD switches
+09:46 < dammsan> Marex: wheat and maybe gose would be nice
+09:46 < Marex> kbingham: that'd be real convenient for restoring U-Boot
+09:47 < Marex> dammsan: ha, I dont think we support wheat in U-Boot (!), so that's another topic
+09:47 < dammsan> would be good to fix
+09:47 < Marex> jupp, and probably easy
+09:47 < dammsan> i suppose blanche is missing as well then
+09:48 < Marex> blanche is there
+09:48 < Marex> but I think anything Gen2 but porter/stout/silk is broken in U-Boot to some degree
+09:48 < Marex> Porter was before I fixed it, so was Silk
+09:49 < Marex> so maybe a round of testing on all things wouldn't hurt
+09:49 < dammsan> inndeed
+09:50 < Marex> plus, test automation for U-Boot, that's something I'm cobbling together in my spare time
+09:50 < Marex> the test.py framework is there, I just need some sort of board control and connector to dammsan 's farm for that
+09:50 < Marex> to be done
+09:51  * Marex stops talking, talks too much anyway
+09:51  * uli___ has to take out the trash, brb
+09:51 < geertu> Managing trash is a very important task in our society!
+09:52 < geertu> uli___: CU!
+09:52 < geertu> Topic 2. Discussion Topics
+09:52 < geertu> a. Should we implement platform_driver.shutdown() on each device driver
+09:52 < geertu>    (especially for master IPs)?
+09:52 < geertu> This is a question from BSP team, relayed through Shimoda-san
+09:53 < geertu> Apparently Morimoto-san will steal the show and explain the rationale behind it?
+09:53 < shimoda_cloud> Morimoto-san had a related question. but he can reply by himself :)
+09:53 < shimoda_cloud> but, I'd still would like to get your opinion about this topic
+09:54 < dammsan> yes?
+09:54 < geertu> What's the use case? What do you want to do in .shutdown()?
+09:55  * geertu tries to keep computers running all the time ;-)
+09:55 < shimoda_cloud> background: If Linux system reboots, IPL do that.
+09:56 < geertu> shimoda_cloud: What do you mean with "IPL do that"?
+09:56 < shimoda_cloud> if IPL changes the DDR setting to "self refresh" and a master IPs are still running, the HW causes to access DDR
+09:56 < shimoda_cloud> greetu: Gen3 ATR will access PMIC to reboot, IIUC
+09:57 < shimoda_cloud> in this case, Gen3 SoCs will stuck because the DDR is in self refresh mode
+09:57 < shimoda_cloud> To stop the HW, BSP team decide to add .shutdown ops to the DU driver
+09:58 < geertu> BTW, what's ATR? ATF?
+09:58 < shimoda_cloud> But, BSP team would like to know all drivers should have same way or not.
+09:59 < shimoda_cloud> geertu: oops, ATF (arm-trusted-firmware)
+09:59 < Marex> shimoda_cloud: what problem are you trying to solve by this ?
+10:00 < dammsan> bus mastering devices are still running when firmware is entering self refresh
+10:00 < Marex> ah
+10:00 < shimoda_cloud> Marex: I'm not trying to solve this now. But, I'd like to give BSP team about upstream team's policy
+10:00 < dammsan> the subsystem is not involved somehow?
+10:00 < shimoda_cloud> dammsan: thanks for simple explanation :)
+10:01 < dammsan> np
+10:01 < geertu> And devices aren't stopped elseway before reboot?
+10:02 < shimoda_cloud> geertu: indeed
+10:03 < Marex> shouldnt the reboot put the system into defined state ?
+10:03 < Marex> q2: doesnt the dram enter self-refresh only during suspend ?
+10:03 < Marex> bbiab
+10:03 < shimoda_cloud> dammsan: i checked roughly yesterday, but the subsystem doesn't have any solutions, I think
+10:04 < geertu> Devices are suspended during system reboot
+10:04 < geertu> Ah, DU doesn't have Runtime PM support yet?
+10:06 < pinchartl> geertu: DU has complex clock handling requirements
+10:06 < geertu> E.g. for sh_eth on Koelsch, genpd_stop_dev() is called before reboot (I still have some local debug code that tells me)
+10:06 < pinchartl> runtime PM is not on the high priority list
+10:06 < dammsan> that would make sense
+10:06 < geertu> pinchartl: I know ;-)
+10:07 < shimoda_cloud> geertu: thanks for the information about Runtime PM. This is easy to know which drivers needs for .shutdown()
+10:08 < shimoda_cloud> s/needs for/needs/
+10:08 < dammsan> shimoda_cloud: is Runtime PM BSP-first?
+10:09 < dammsan> the dependencies between different DU devices seem quite complex to me
+10:11 < shimoda_cloud> dammsan: IIUC, almost all drivers have already supported Runtime PM
+10:12 < geertu> The DU node in DT also doesn't have a power-domains property.
+10:12 < dammsan> it would be good to fix that
+10:13 < shimoda_cloud> some drivers (e.g. ehci-platform) lack Runtime PM though...
+10:13 < geertu> Yep, separate device nodes for each channel, linked with "companion" properties
+10:13 < dammsan> can't we have bus notifier in soc code to handle PM in such case?
+10:16 < dammsan> BUS_NOTIFY_BIND_DRIVER
+10:16 < dammsan> and a white list
+10:16 < geertu> dammsan: That feels like the legacy clock domain to me...
+10:16 < dammsan> as a temporary solution
+10:16 < dammsan> might be better
+10:17 < dammsan> i guess fixing up DT can be separated from actual SW implementation
+10:18 < geertu> We've slowly entered MultiMedia space...
+10:18 < pinchartl> let me know when you'll have fully entered multimedia space and I'll take over :-)
+10:19 < geertu> I think we have, unless there's another core topic to discuss?
+10:19 < pinchartl> (you have 60s, the tea water is heating up)
+10:19 < shimoda_cloud> thanks! I have no core topic from my side
+10:20 < kbingham> Except I was going to ask about DMAC virtualisation :)
+10:20 < pinchartl> (which always reminds me of the 御茶ノ水 metro station in Tōkyō)
+10:21 < pinchartl> kbingham: please go ahead
+10:21 < dammsan> kbingham: seems like an important topic
+10:22 < kbingham> dammsan, geertu: mainly - what's the method of use-case testing.
+10:22 < dammsan> sertest inside the guest using a loopback? =)
+10:22 < dammsan> not sure if it makes sense
+10:23 < kbingham> dammsan, From multiple guests ?
+10:23 < dammsan> i think testing a single guest is enough, but designing code for multi-guest
+10:24 < kbingham> Ok so just exposing two serial devices into the guest - which then have a loopback.
+10:24 < dammsan> for instance
+10:24 < geertu> kbingham: That needs wiring.
+10:24 < kbingham> geertu, It's the wiring that confuses me ...
+10:24 < dammsan> something very basic is also ok with me
+10:24 < geertu> Can't you just use the second serial port (debug serial)
+10:25 < geertu> Tie it to USB, and you can talk to it from the host
+10:25 < dammsan> that seems even better
+10:25 < kbingham> as the serial ports on salvatorx are USB gadgets :)
+10:25 < kbingham> Ok - so just take the serial and use it as a serial device :)
+10:25 < kbingham> (as a usb serial device)
+10:26 < geertu> Once it works, you can use that serial as the console for the guest
+10:26 < geertu> And wire it up in your farm ;)
+10:27 < dammsan> it is hard to beat virsh console
+10:27 < dammsan> but hey
+10:28 < dammsan> using the second debug serial console sounds great
+10:28 < dammsan> if it supports SYS-DMAC that is
+10:28 < kbingham> Is USB already supported through the guest ?
+10:28 < kbingham> Or does it just do high level USB passthrough ...
+10:29 < geertu> kbingham: Use USB on the host, please ;-)
+10:29 < kbingham> (or in your test, do you mean then read the 'guest serial' on the 'host USB serial'
+10:29 < kbingham> Ok - that's clearer - I thought this was some loopback out of the guest, then back into the guest.
+10:30 < kbingham> Ok - well until I dive in and hit problems that's enough for me :)
+10:30 < geertu> kbingham: You can also run https://github.com/geertu/sertest on the guest, and on the host
+10:31 < geertu> guest=SCIF1 host=cp210x-usb-serial
+10:32 < kbingham> geertu, Thanks for the sertest link - I'll get that going too.
+10:33 < kbingham> Final question - was it left that I am writing the task description?
+10:34  * kbingham was expecting to receive a description ... but that may not be the case
+10:34 < geertu> I think so
+10:34 < kbingham> geertu, Ok - I'll pull something together and run it past you.
+10:34 < geertu> kbingham: Thanks!
+10:35 < dammsan> thanks guys
+10:35 < geertu> pinchartl: FFWD to MM?
+10:35 < geertu> Thaks for joininh, and have a nice continued day!
+10:35 < geertu> s/joininh/joining/