1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
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!
|
