10:00 < wsa_> let's start the IO meeting
10:01 < wsa_> welcome all!
10:01 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi
10:01 < wsa_> hi magnus!
10:01 < dammsan> hi guys
10:01 < wsa_> what about Vaishali? Is she on the list now?
10:01 < dammsan> not yet i think
10:02 < wsa_> I see
10:02 < wsa_> okay, then let's start with the status updates:
10:02 < wsa_> A)
10:02 < wsa_>         Marek: picked up PCIe patches again.
10:02 < wsa_>         Geert: enabled MSIOF on M3-N
10:02 < wsa_>         Niklas: started with Thermal upporting
10:02 < wsa_>         Shimoda-san: USB bugfix and role swap prototype
10:02 < wsa_>         Ulrich: sent out new version of HSCIF sampling point
10:02 < wsa_>         Wolfram: SDHI DMA RX workaround, re-test I2C double NACK issue
10:02 < wsa_>                  upporting I2C & SDHI, scheduling upporting tasks
10:02 < wsa_> B)
10:02 < wsa_>         Marek: send out new version of PCIe patches
10:02 < wsa_>         Niklas: continue thermal upporting and start with SDHI
10:02 < wsa_>                 check if H3 ES3.0 has thermal fuses
10:02 < wsa_>         Shimoda-san: continue role swap, check Wolfram's SDHI patch,
10:02 < wsa_>                      USB PHY GPIO support
10:02 < wsa_>         Ulrich: upporting
10:02 < wsa_>         Wolfram: I2C & SDHI upporting, talk to QEMU devs about I2C passthrough
10:02 < wsa_> C)
10:02 < wsa_>         Wolfram: recreating test cases for BSP patches is time-consuming
10:03 < wsa_> not super much going on. It is the no-add.-task-phase + easter
10:03 < wsa_> are there questions to that?
10:04 < wsa_> (not to easter ;))
10:04 < wsa_> otherwise I would re-cap and continue the discussion about upporting
10:04 < wsa_> which is hi-prio now
10:04 < wsa_> and we all have extended base time for that
10:05 < wsa_> meaning that add. tasks in IO will currently need a special request
10:05 < wsa_> so, please talk to me if you have one
10:06 < wsa_> otherwise I would like to discuss "assignments" to IP cores now
10:06 < wsa_> meaning taking care of those BSP patches for upstreaming
10:07 < wsa_> in the order as I discovered them in the html-report file
10:07 < wsa_> Marex: do you have bandwidth for the PCIe patches?
10:07 < wsa_> I heard that jmondi has some capacity left ;)
10:08 < Marex> wsa_: I am doing what I can
10:08 < Marex> wsa_: whats left is just resubmit them anyway
10:09 < wsa_> Sure you are doing what you can, no doubts here
10:09 < wsa_> just wondering if you are overloaded and open for assistance or if everything is fine
10:10 < Marex> wsa_: it should be fine
10:10 < wsa_> OK, thanks!
10:10 < wsa_> wsa_: you are doing I2C/IIC?
10:10 < wsa_> sure
10:11 < wsa_> SDHI is a big beast
10:11 < wsa_> I asked neg to assist in the upporting efforts and he agreed (thanks!)
10:11 < wsa_> I will be there, too
10:12 < wsa_> and Simon has experience in this field as well
10:12 < Marex> wsa_: did you get SDHI to up-calibrate from HS200 to HS400 ?
10:12 < wsa_> Marex: Simon did and it worked for me
10:12 < Marex> OK, I'll talk to him
10:13 < wsa_> there are lots of patches for SDHI, so making a plan when to upstream what is still WIP
10:13 < wsa_> (especially given the problem to recreate the test cases)
10:14 < wsa_> but I think we have a good team to handle that
10:14 < wsa_> shimoda: are you still okay with supporting PWM?
10:15 < wsa_> same question about being overloaded :)
10:15 < wsa_> if you are fine, I am, too
10:15 < shimoda> wsa_: yes. I'm ok with supporting PWM
10:15 < wsa_> good, thank you
10:16 < wsa_> RAVB is planned for Simon who is not here yet
10:16 < wsa_> uli___: can you take care of the SCIF patches?
10:16 < wsa_> they are not much
10:16 < wsa_> but still
10:16 < uli___> can do
10:16 < wsa_> thx!
10:17 < wsa_> geertu: you already did MSIOF. are you fine with keeping that?
10:17 < geertu> wsa_: Sure
10:17 < wsa_> great
10:18 < wsa_> for updating DTS files, we asked Kaneko-san to do it. Let's see how that goes, if he needs further assistance, etc...
10:19 < wsa_> neg: you are the thermal guy, right? :)
10:19 < neg> yes :-)
10:19 < wsa_> good
10:20 < wsa_> shimoda-san is also still our USB hero
10:20 < shimoda> wsa_: yes :)
10:20 < wsa_> i think most USB patches in the BSP are already taken care of
10:20 < wsa_> Thank you!
10:21 < shimoda> wsa_: i think so!
10:21 < wsa_> for watchdog, I asked Vaishali to work on that and she already started
10:22 < geertu> watchdog is M3-N enablement?
10:22 < wsa_> jmondi: there doesn't seem to be an IP core left, but I'd be surprised if there wasn't something unexpected showing up
10:23 < wsa_> jmondi: would that be OK for you, doing various stuff?
10:23 < wsa_> watchdog is basically adding PM
10:23 < jmondi> wsa_: no worries, as I've said I welcome a task to alternate with multimedia, but I should wait to see how AT proposed by Laurent are assigned
10:23 < wsa_> but since the code is HW independent, the task is to try to implement a generic solution
10:23 < jmondi> I might find myself full again in a bit :)
10:24 < wsa_> heh
10:24 < geertu> PM == suspend/resume?
10:24 < wsa_> yes
10:25 < geertu> linux-next 07278ca1ccc9a124 ("watchdog: renesas_wdt: Add suspend/resume support")
10:25 < wsa_> uli___: one more thing, you still have the D3?
10:25 < uli___> i do
10:26 < wsa_> to my knowledge, we haven't enabled MSIOF there yet
10:26 < wsa_> do have an SPI device to attach and do that?
10:26 < wsa_> and time to do that?
10:27 < uli___> i think so
10:27 < wsa_> geertu: uuuh, right
10:28 < wsa_> geertu: need to think if the generic solution still makes sense
10:28 < wsa_> uli___: thanks!
10:29 < wsa_> so, that was it from my side
10:29 < shimoda> wsa_: how about sata?
10:30 < shimoda> and I have a question about sdhi whitelist again :)
10:30 < wsa_> shimoda: right, this is not much. I can do that if noone else volunteers
10:31 < shimoda> wsa_: i got it.
10:31 < wsa_> shimoda: fire away
10:31 < wsa_> the whitelist question
10:32 < shimoda> about sdhi whitelist, bsp team would like to know about future plan of upstream team.
10:32 < shimoda> now the whitelist has M3 ES1.0 for instance, but we will have M3 ES1.1 and ES1.2
10:33 < shimoda> in this case, how do we take care of adding support these new SoCs revision?
10:34 < wsa_> I thought the idea was to remove the revision field for the "generic" entries
10:34 < wsa_> (i.e. not the ones needing the DMA RX quirk)
10:34 < geertu> In all other cases (except IPMMU), we have blacklists.
10:34 < wsa_> I haven't done this in the DMA RX quirk patch yet because this is a seperate issue
10:34 < geertu> SDHI is special because of the internal vs. external DMAC issue?
10:35 < wsa_> yes
10:36 < wsa_> and the possibility that some SoC could have both DMA
10:36 < wsa_> shimoda: I hope I got all that right. Or did I misunderstand something?
10:38 < shimoda> wsa_: i also think removing the revision field for the "generic" entries is good idea. But, is it conflict with DMA RX quirk?
10:38 < shimoda> or we can support both?
10:38 < wsa_> I think so but I still need to test that :)
10:39 < wsa_> I'd think we can have specific entries first, and then more generic ones as fallback
10:39 < shimoda> wsa_: i got it :) If so, I'll answer this plan to BSP team. thanks!
10:39 < wsa_> shimoda: good :)
10:39 < wsa_> dammsan: anything left from your side?
10:41 < wsa_> ok, then, there is still email for further issues
10:41 < dammsan> not much
10:41 < dammsan> thanks for your assistance
10:42 < wsa_> sure, you're welcome
10:42 < wsa_> geertu: then, prepare to grab the mic
10:42 < wsa_> here it comes
10:42  * geertu is preparing
10:42  * wsa_ throws
10:42  * geertu catches
10:42 < wsa_> \o/
10:42 < wsa_> thanks all!