1 files changed, 128 insertions, 0 deletions
diff --git a/wiki/Chat_log/20181004-io-chatlog b/wiki/Chat_log/20181004-io-chatlog
new file mode 100644
index 0000000..7fb21bd
--- /dev/null
+++ b/wiki/Chat_log/20181004-io-chatlog
@@ -0,0 +1,128 @@
+09:07 < wsa_> okay, let's start the IO meeting then
+09:07 < wsa_> here are the status updates
+09:08 < wsa_> Status updates
+09:08 < wsa_> ==============
+09:08 < wsa_> A - what have I done since last time
+09:08 < wsa_> ------------------------------------
+09:08 < wsa_> Geert
+09:08 < wsa_> : made a small MSIOF test rig fitting Ebisu and Draak containing an EEPROM,
+09:08 < wsa_>   fixed workqueue-related issues on suspend/unbind in thermal drivers
+09:08 < wsa_> Marek
+09:08 < wsa_> : handled Linux PCIe 32bit DMA test feedback
+09:08 < wsa_> Niklas
+09:08 < wsa_> : started rework for v2 SDHI reset series and sent sent next version of the
+09:08 < wsa_>   interrupt initialization patch
+09:08 < wsa_> Shimoda-san
+09:08 < wsa_> : sent patches for D3/E3 support for renesas_usbhs and phy-rcar-gen3-usb2,
+09:08 < wsa_>   and E3 support for gadget/udc/renesas_usb3. Also, finished investigating
+09:08 < wsa_>   the eMMC suspend issue
+09:08 < wsa_> Simon
+09:08 < wsa_> : upstreamed removal of 4 byte alignment and fixed a regression in link
+09:08 < wsa_>   negotiation, both for RAVB
+09:08 < wsa_> Ulrich
+09:08 < wsa_> : re-checked "serial: sh-sci: Use pm_runtime_get_sync()/put()"
+09:08 < wsa_> Wolfram
+09:08 < wsa_> : sent RFCs for irqless I2C transfers to communicate very late and for
+09:08 < wsa_>   rejecting transfers after noirq suspend stage, reviewed various patches
+09:08 < wsa_>   for SDHI and I2C, upported patches for SCIF and BD9571
+09:08 < wsa_> B - what I want to do until next time
+09:08 < wsa_> -------------------------------------
+09:08 < wsa_> Geert
+09:08 < wsa_> : wants to test E3 MSIOF DMAC if patches are ready
+09:08 < wsa_> Kaneko-san
+09:08 < wsa_> : wants to upport E3 MSIOF DMAC enablement
+09:08 < wsa_> Marek
+09:08 < wsa_> : wants to go back to PCIe SError again
+09:08 < wsa_> Niklas
+09:08 < wsa_> : wants to find a good solution to 4-tap clock issue
+09:08 < wsa_> Shimoda-san
+09:08 < wsa_> : wants to work on KVM + QEMU + USB
+09:08 < wsa_> Simon
+09:08 < wsa_> : wants to investigate RAVB no-link patches in BSP 3.7.2
+09:08 < wsa_> Ulrich
+09:08 < wsa_> : prepares for stay in the Philippines until Dec 10
+09:08 < wsa_> Wolfram
+09:08 < wsa_> : wants to continue with above I2C PM related tasks and continue upporting
+09:08 < wsa_>   patches for SDHI and I2C
+09:08 < wsa_> C - problems I currently have
+09:08 < wsa_> -----------------------------
+09:08 < wsa_> Wolfram
+09:08 < wsa_> : needs more time with I2C PM as expected.
+09:08 < wsa_> my questions:
+09:09 < wsa_> neg: what about the SD clock divider patches? Can you give them priority because we need them to enable HS400?
+09:10 < wsa_> neg: or does the reset issue fix a set of problems I am currently unaware of?
+09:10 < wsa_> morimoto: is it correct to not update BSP-ticket files older than 'bsp370'?
+09:11 < morimoto> on what ?
+09:11 < wsa_> in other words, I only update 'bsp370' now and consider the other ones "v4.x" outdated
+09:11 < wsa_> periupport
+09:11 < morimoto> My understanding is that basically we want to 100% done all ticket on periupport
+09:12 < morimoto> if possible
+09:12 < morimoto> next ver bsp380 (?) can be started on new tool
+09:12 < morimoto> Is this good answer for you ?
+09:12 < horms> morimoto: I think this is not a question about what to do, but rather what to track
+09:12 < horms> Currently we have bsp70 4.14 and 4.9 tickets
+09:12 < morimoto> Yes
+09:12 < neg> wsa_: sure I can try and move it up on the list, my plan was to work on that after ELCE during the SDHI hacking days as that issue has the most unclear solution to me at this time
+09:13 < horms> Can we assume that all relevant tickets are included in bsp370 and ignore the old 4.14 and 4.9 tickets because they are assumed to be duplicates
+09:13 < wsa_> neg: ah, this is included in the "4tap" task?
+09:13 < morimoto> If working for v4.x is too old or impossible, I think we can skip
+09:13 < horms> Or do we need to keep tracking all bsp370 4.14 and 4.9 tickets
+09:13 < horms> with all duplicates?
+09:13 < morimoto> horms: Ohh, yes, I think so
+09:14 < horms> ok, i think that was wsa_'s question
+09:14 < wsa_> horms: thanks for the clarification. that was exactly what i meant
+09:14 < horms> One thing on the BSP: I expect BSP 3.7.2 will be released today or tomorrow
+09:14 < neg> wsa_: yes that is core problem of the 4-tap clock issue, maybe I should use a better description for the task, sorry about that
+09:15 < wsa_> neg: ok, good
+09:15 < shimoda> horms:  "with all duplicates" means these tickets (bsp370, 4.14, 4.9) have duplicate commits?
+09:16 < horms> shimoda: yes, maybe with different commit ids due to rebasing
+09:16 < wsa_> neg: please note that Geert won't be at the SDHI hackfest (and probably not available by mail because it is a weekend).
+09:16 < horms> shimoda: so its a bit of extra work to update the duplicate tickets
+09:17 < wsa_> neg: so, some discussion beforehand might be helpful?
+09:17 < neg> wsa_: I agree that is something to handle and as you suggest try to discuss beforehand with geertu
+09:19 < wsa_> thanks
+09:19 < geertu> wsa_: I'll be stuck in Edinburgh until my late afternoon flight
+09:19 < wsa_> geertu: which day?
+09:20 < geertu> wsa_: Saturday
+09:21  * geertu has never been to Edinburh before, so there may be more interesting things to visit ;-)
+09:21 < wsa_> good to know
+09:21 < morimoto> horms: sorry maybe I answered strange things for you.
+09:21 < wsa_> SDHI hackfest will not be in Edinburgh, though
+09:21 < wsa_> but close
+09:21 < neg> geertu: more interesting that solving clock divider problmes? What could it possibli be? :-)
+09:22 < wsa_> I think we will see at "runtime", but let's plan for you having some sightseeing time in Edinburgh :)
+09:22 < horms> morimoto: I'm fine with your answer. The overhead is managable for now, IMHO
+09:22 < morimoto> we can ignore 4.9. basically 4.14 and bsp370 have no coflictl
+09:22 < morimoto> s/conflictl/conflict/
+09:23 < morimoto> We want to focus 4.14 and bsp370
+09:23 < Marex> wsa_: btw re that pci stuff, I am thinking of implementing U-Boot PCI driver for Gen3, so I can have faster turnaround when testing the ATF SError handling
+09:23 < wsa_> v4.9 is horribly outdated by now
+09:23 < morimoto> was_: yes, let's ignore it.
+09:24 < wsa_> v4.14 needs a little backporting; but, yes, managable
+09:25 < wsa_> I will create a periperi meeting page in our wiki today
+09:25 < wsa_> I liked the collection of who leaves when and stays where and what we planned
+09:26 < wsa_> Marex: ok
+09:26 < wsa_> Marex: is it just for faster turnaround time, or is there a use case? :)
+09:26 < shimoda> horms: thanks, as morimoto-san mentioned, to avoid a bit of extra work, let's stop v4.9 updating
+09:27 < Marex> wsa_: faster turnaround, but maybe there could be a usecase
+09:27 < Marex> wsa_: it shouldn't take long to write the driver
+09:27 < horms> shimoda: thanks, got it
+09:28 < geertu> Marex: Intel Ethernet TFTP?
+09:28 < geertu> Marex: Remote DMA using IEEE-1394?
+09:29 < geertu> Marex: nVidia U-Boot splashscreen?
+09:29 < wsa_> geertu, uli___ : there is a SCIF patch left for upporting, is one of you interested?
+09:29 < wsa_> sci: sh-sci: Fix transfer sequence of unsupport DMA transfer(6beb1f98d3bd30) 
+09:30 < uli___> i can do it
+09:30 < wsa_> uli___: thanks!
+09:31 < geertu> probably we should lower that message from dev_warn to dev_dbg?
+09:31 < Marex> geertu: which one of those is exactly useful for us ? ;-)
+09:32 < Marex> geertu: I think if you have an option rom, you can run option roms, so the posibilities grow even further ...
+09:32 < wsa_> okay, any more questions from your side?
+09:32 < Marex> geertu: I think if you have an option rom in your hardware, you can run it, so the posibilities grow even further ...
+09:33 < Marex> (I need coffee)
+09:33 < geertu> Marex: Remote DMA may allow to read ATF-protected memory?
+09:33 < Marex> geertu: we should make sure this is actually NOT possible ;-)
+09:34 < Marex> geertu: that's the point of the memory being protected
+09:34 < wsa_> okay, then
+09:34 < wsa_> thanks for this meeting
+09:35 < wsa_> geertu: the stage is yours!