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