wiki: Porting wiki: Porting Chat Log

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

1 files changed, 106 insertions, 0 deletions

diff --git a/wiki/Chat_log/20191107-io-chatlog b/wiki/Chat_log/20191107-io-chatlog
new file mode 100644
index 0000000..de037a5
--- /dev/null
+++ b/wiki/Chat_log/20191107-io-chatlog
@@ -0,0 +1,106 @@
+09:08 < wsa_> so, let's start the IO meeting then
+09:08 < wsa_> status updates
+09:08 < wsa_> A - what have I done since last time
+09:08 < wsa_> ------------------------------------
+09:08 < wsa_> Geert
+09:08 < wsa_> : investigated the MAX9611 boot failure issue, soldered some wires to his
+09:08 < wsa_>   Salvator-X (H3 ES1.0), and found out that the bus speed is slightly too
+09:08 < wsa_>   high
+09:08 < wsa_> Marek
+09:08 < wsa_> : continued discussion on the PCI dma-ranges, resubmitted the PCI
+09:08 < wsa_>   dma-ranges patches, and started cleaning up the downstream patchset
+09:08 < wsa_>   for OpTee
+09:08 < wsa_> Shimoda-san
+09:08 < wsa_> : submitted multiple patches to convert binding docs to YAML, fixed issues
+09:08 < wsa_>   in the PCI, USBHS and USN gadget drivers
+09:08 < wsa_> Ulrich
+09:08 < wsa_> :
+09:08 < wsa_> Wolfram
+09:08 < wsa_> : sent out two larger series for I2C API conversion and prepared some I2C
+09:08 < wsa_>   core cleanups, went to ELCE and gave a talk and discussed dynamic address
+09:08 < wsa_>   assignments there, started looking into new BSP patches about HS400,
+09:08 < wsa_>   reviewed and/or tested SDHI, MMC core, I2C, RAVB patches
+09:08 < wsa_> B - what I want to do until next time
+09:08 < wsa_> -------------------------------------
+09:08 < wsa_> Geert
+09:08 < wsa_> : wants to continue debugging the MAX9611 issue
+09:08 < wsa_> Marek
+09:08 < wsa_> : wants to continue with OpTee work
+09:08 < wsa_> Shimoda-san
+09:08 < wsa_> : wants to collect information about "R-Car Gen4" hardware IPs
+09:08 < wsa_> Ulrich
+09:08 < wsa_> : wants to
+09:08 < wsa_> Wolfram
+09:08 < wsa_> : wants to finish SCC clock handling for SDHI, update SDHI manual calibration,
+09:08 < wsa_>   assist Geert with MAX9611 issue, do more I2C API conversions
+09:08 < wsa_> C - problems I currently have
+09:08 < wsa_> -----------------------------
+09:08 < wsa_> Wolfram
+09:08 < wsa_> : has a disagreement with MMC maintainer how to handle pinctrl failures
+09:08 < wsa_>   during probe (bail out or not)
+09:09 -!- Irssi: #periperi: Total of 16 nicks [0 ops, 0 halfops, 0 voices, 16 normal]
+09:09 < wsa_> uli is missing. does someone know about him?
+09:10 < wsa_> Marex: the OpTee work, is it for U-Boot or both Linux/U-Boot
+09:10 < wsa_> ?
+09:11 < Marex> wsa_: neither
+09:11 < wsa_> ATF?
+09:11 < Marex> wsa_: it's separate from everything
+09:11 < Marex> wsa_: it's another component
+09:11 < Marex> wsa_: optee OS is that secure-world operating system
+09:12 < Marex> wsa_: it co-exists with Linux, has access to everything (because it's secure) and Linux can call into it via syscall interface
+09:12 < jmondi> 'morning, sorry for being a bit late
+09:13 < wsa_> Is that generic meanwhile? Because we have BSP-specific patches...
+09:14 < Marex> wsa_: what , optee ?
+09:14 < wsa_> the syscall interface
+09:15 < Marex> wsa_: the syscall interface is (except for custom renesas syscalls for RPC access)
+09:15 < Marex> those custom syscalls are not yet mainline, and probably wont ever be
+09:15 < wsa_> if somebody wants to add an opinion to the disagreement I have with Ulf, this is the thread BTW: [PATCH] mmc: renesas_sdhi: add checks for pinctrl_lookup_state
+09:15 < geertu> wsa_: So OpTee is core
+09:15 < wsa_> Marex: ok, this is a clear answer :)
+09:16 < wsa_> (well, except for "probably", but still gives me an idea)
+09:16 < Marex> but yes, it's core
+09:17  * geertu reads mmc: renesas_sdhi: add ...
+09:19 < wsa_> shimoda: we removed Gen3 blacklisting from SDHI SYS_DMAC. Do you think we could also remove white listing Gen3 from SDHI Internal DMAC? And just make it a quirk table for those SoCs which have quirks?
+09:20 < wsa_> We need to add every now SoC revision and I don't see value since we dropped black listing from SYS DMAC. But maybe I am overlooking something?
+09:20 < geertu> wsa_: This it not just for UHS, but also for the default state?
+09:20 < geertu> So preventing 1.8v modes is not the only failure mode
+09:21 < wsa_> hmmm, yes
+09:21 < wsa_> unless the firmware did the initial setup, but we shouldn't rely on this
+09:21 < geertu> But "state_uhs" is optinal. What does pinctrl_lookup_state() return if it's just missing?
+09:22 < geertu> s/optinal/optional/
+09:22 < geertu> Ah, -ENODEV, unless pinctrl_dummy_state is true (yikes)
+09:24 < wsa_> geertu: any assistance you need for the MAX9611 debugging? As mentioned, I will scope some busses on some devices, too
+09:25 < wsa_> pinchartl: you there?
+09:25 < geertu> wsa_: I'll try the slower speed.  If that fails, I'm afraid I will be blocked, as I don't think my SmartScope can capture all of the i2c4 actitivity during boot.
+09:25 < jmondi> geertu: is the max9611 issue the POR  one ?
+09:25 < geertu> jmondi: Yes
+09:25 < shimoda> wsa_:  Do you mean the converting white list to black list (quirks)? if so, i agree :)
+09:26 < jmondi> ah! thanks for investigating!
+09:27 < wsa_> shimoda: not black list as in "forbid SDHI with that device" but as in "use this quirk with that device"
+09:27 < wsa_> so, basically remove everything below "/* generic ones */" and adapt the code accordingly
+09:27 < wsa_> other questions from your side?
+09:28 < Marex> wsa_: yes
+09:28 < Marex> wsa_: do you have the manual calibration patches somewhere ? I would like to take a look
+09:28 < Marex> wsa_: seems we will have to add that into U-Boot as well, HS200 is not sufficient
+09:29 < wsa_> you mean my reworked ones?
+09:29 < Marex> wsa_: probably, I dont know in what state that work is on your end
+09:30 < wsa_> https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/log/?h=renesas/topic/sdhi-manual-calib
+09:30 < Marex> wsa_: thanks
+09:30 < wsa_> this needs to be adapted to the latest BSP patches...
+09:31 < wsa_> I agreed with Shimoda-san that DT configuration for all this is not needed upstream
+09:31 < shimoda> wsa_: removing everything below "generic ones" sounds good to me.
+09:31 < wsa_> so that part from the BSP can be skipped
+09:31 < Marex> right
+09:31 < wsa_> shimoda: cool, thanks!
+09:32 < Marex> I suspect this special tuning might take longer than loading that one file from the eMMC in U-Boot, but we will see
+09:32 < wsa_> shimoda: and I am looking forward to your Gen4 IP research results :)
+09:33 < shimoda> wsa_: :)
+09:33 < geertu> wsa_: needs to be adapted to the latest mainline or mmc-next, too
+09:34 < wsa_> Marex: if you want to measure that, and have numbers for it, I think it makes sense to share them
+09:34 < geertu> The branch was dropped from renesas-drivers as it contains a commit that has been upstream
+09:34 < geertu> s/been/been reverted/
+09:34 < Marex> wsa_: I didn't implement it yet, so I dont
+09:35 < wsa_> Marex: yeah, I was talking future here :)
+09:36 < wsa_> so, any other questions?
+09:37 < wsa_> if not, then I'll pass the mic to you, Geert
+09:37 < wsa_> thanks everyone for this meeting!