path: root/wiki/Chat_log/20180524-core-chatlog

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/