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!