wiki: Porting wiki: Porting Chat Log

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 138 insertions, 0 deletions

diff --git a/wiki/Chat_log/20180405-io-chatlog b/wiki/Chat_log/20180405-io-chatlog
new file mode 100644
index 0000000..cded704
--- /dev/null
+++ b/wiki/Chat_log/20180405-io-chatlog
@@ -0,0 +1,138 @@
+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!