diff options
Diffstat (limited to 'wiki/Chat_log/20191107-io-chatlog')
| -rw-r--r-- | wiki/Chat_log/20191107-io-chatlog | 106 |
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! |