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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
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!
|
