summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20180726-io-chatlog
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/Chat_log/20180726-io-chatlog')
-rw-r--r--wiki/Chat_log/20180726-io-chatlog65
1 files changed, 65 insertions, 0 deletions
diff --git a/wiki/Chat_log/20180726-io-chatlog b/wiki/Chat_log/20180726-io-chatlog
new file mode 100644
index 0000000..7b6ac76
--- /dev/null
+++ b/wiki/Chat_log/20180726-io-chatlog
@@ -0,0 +1,65 @@
+09:03 < wsa_> Welcome to the IO meeting!
+09:04 < wsa_> As mentioned in my mail, I couldn't prepare a summary this time, so I will start with questions I have about the reports you sent
+09:04 < wsa_> and/or about upport status
+09:04 < wsa_> geertu: I noticed some suspend/resume patches in periupport which have no further comments
+09:04 < wsa_> for msiof
+09:05 < wsa_> do you know about them?
+09:05 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi
+09:05 < morimoto> Hi
+09:05 < wsa_> other than that, thanks for the suggestions about SATA, I think we are on a good path there
+09:05 -!- ulih [~Mutter@x2f7feb1.dyn.telefonica.de] has quit Quit: Mutter: www.mutterirc.com
+09:06 < wsa_> hi morimoto-san
+09:06 < geertu> wsa_: I'll have a look again
+09:06 < wsa_> thanks!
+09:07 < wsa_> neg: about using !4tap in your newest patch series. We got that behaviour from the BSP, right? Does it make sense to get some confirmation from the HW team?
+09:08 < wsa_> Or do you understand why it is not needed in this case? I have to admit, I don't.
+09:08 < horms> Unfortunately I have no insight beyond the BSP code
+09:09 * wsa_ wonders if neg fell asleep again to win another bottle of schnaps...
+09:10 < Marex> wsa_: the SDHI chapter from new release of the datasheet explains the !4tap better, maybe that's where it came from ?
+09:11 < wsa_> shimoda: would you be so kind and send me a diff for the USB tasks in peripelist/io/todo? I think the tasks got more detailed and I am not sure I can map it properly.
+09:11 < shimoda> wsa_: about upport status of "M,090dcb6d8ad59559610dc51b62636a74b6ac1d4a", bsp team agree about this marks to 'N'
+09:11 < shimoda> wsa_: I'll check the todo
+09:12 < wsa_> Marex: does it explain why to not read SCC errors? I can't recall but just might have missed it...
+09:12 < Marex> wsa_: oh that one, where you shouldn't read the SCC error register in HS400 mode ? :)
+09:13 < wsa_> pinchartl: jmondi: I hope you like the new SCCB handling, too? I think it is an elegant solution :)
+09:13 < Marex> wsa_: I think the whole HS400 switch is real simple, which is what the SDHI tries to explain in a tad clumsy way
+09:14 < wsa_> And it gets rid of the "implement I2C_M_STOP" task for i2c-rcar...
+09:14 < Marex> wsa_: you don't need to calibrate again for the HS400
+09:14 < pinchartl> wsa_: I've always thought that regmap had a bit too large overhead for my tastes, but apart from that, yes, it's all fine
+09:14 < Marex> wsa_: that's why you don't need to read the SCC register I think
+09:15 < pinchartl> but I2C_M_STOP should still be implemented, don't you think ? :-)
+09:15 < wsa_> Marex: but 8 tap vs 4 tap has nothing to do with HS400. It is only different between SoC versions...
+09:15 < geertu> wsa_: H3 switches between 4 and 8 taps for HS200 vs. HS400
+09:16 < Marex> wsa_: from what I understand, on Gen3, it's 8 tap in HS200 and 8/4 tap in HS400 depending on SoC
+09:16 < wsa_> shimoda: thanks for checking the todo
+09:17 < wsa_> huh?
+09:17 < neg> Sorry for oversleeping, just got hear reading up on the backlog
+09:17 < wsa_> We need to clarify this understanding :) But this is better done by email I'd think
+09:17 < wsa_> Unless neg doesn't have that killer arguemt ;)
+09:18 < Marex> wsa_: read the latest SDHI chapter, this information is right at the end ;-)
+09:18 < wsa_> I will read it (again)
+09:20 < wsa_> uli___: thanks for the interest in the scif task, I will add you to the task
+09:20 < neg> No argument beyond the BSP so probobly email is a good idea
+09:20 < Marex> wsa_: R-CarH3_M3_05_70_71_SDHI_MMC_0019_e.pdf this is what I'm reading, but I hear there's something even newer
+09:20 < wsa_> uli___: i think there is also SCIF suspend/resume patches open (which shouldn't be much work from what I recall)
+09:21 < wsa_> there is 0024
+09:21 < wsa_> and I found the last chapter a bit confusing with the latest additions
+09:22 < Marex> wsa_: the 0019 was nice and clear, so that helped me understand it a bit better
+09:22 < wsa_> we should discuss our understanding on periperi, that's a good idea, me thinks
+09:23 < wsa_> vaishali_cloud: are you here?
+09:24 < vaishali_cloud> wsa_: Yes, for next 20 minutes. Have to enter visa office after that :)
+09:24 < vaishali_cloud> s/enter/enter in
+09:24 < wsa_> good luck with the visa office!
+09:25 < shimoda> wsa_: i sent an email about io/todo of usb tasks
+09:25 < wsa_> I wanted to know if you have everything you need for stress-testing SDHI suspend/resume?
+09:26 < wsa_> the above was for vaishali_cloud (triggering notification again ;))
+09:26 < vaishali_cloud> wsa_: dammsan is going to get back to me today. I'll email you after that.
+09:27 < wsa_> okay
+09:27 < vaishali_cloud> Thanks for being patient on that. :)
+09:27 < wsa_> if you have not started yet, it might make sense to start with suspend/resume for the GPIO multiplexer we need for SATA
+09:28 < wsa_> but I'll wait for your email
+09:28 < wsa_> and respond to that
+09:28 < wsa_> That's all from my side, any questions from your side?
+09:29 < vaishali_cloud> wsa_: Sure, I'll check that too.
+09:30 < wsa_> ok, then, my time is up!
+09:30 < wsa_> thanks all for this meeting