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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
|
Core-chat-meeting-2017-11-09
09:38 < geertu> Welcome to today's core group meeting!
09:38 < geertu> Agenda:
09:38 < geertu> 1. Status updates
09:38 < geertu> 2. Discussion Topics
09:38 < geertu> Topic 1. Status updates
09:39 < geertu> I'll just replay (a sometimes shortened version of) the update sent by email
09:39 < geertu> A) What have I done since last time
09:39 < geertu> Geert:
09:39 < geertu> - Sent 2nd pull requests for clk-renesas and sh-pfc,
09:39 < geertu> - Attendend ELCE and DT Workshop (Thursday),
09:39 < geertu> - Sent patches to enable SMP on r8a77970/eagle,
09:39 < geertu> - Sent patches for initial support for Salvator-XS with R-Car M3-W.
09:39 < geertu> - Looked a bit into initial support for Salvator-X with R-Car M3-N.
09:39 < geertu> - Fixing genpd for wake-up devices:
09:39 < geertu> - Sent active_wakeup cleanups,
09:39 < geertu> - Working on part two (interrupt routing),
09:39 < geertu> Jacopo:
09:39 < geertu> - Attended ELCE and multimedia meeting on 26/27 November
09:39 < geertu> Marek:
09:39 < geertu> - UBoot: Fixed eMMC data line voltage setting bug in U-Boot DT
09:39 < geertu> - UBoot: Final testing in preparation for the 2017.11 release
09:39 < geertu> Morimoto:
09:39 < geertu> - Posted DMAC TCR/TCRB patch
09:39 < geertu> Niklas:
09:39 < geertu> - [PATCH] net: ethtool: remove error check for legacy setting transceiver
09:39 < geertu> type
09:39 < geertu> - Received a V3M.
09:40 < geertu> Shimoda:
09:40 < geertu> - Prepared test environment for a new feature of M3-N's IPMMU (stage-2
09:40 < geertu> format).
09:40 < geertu> - Handle our 3rd party (EPAM) requests for Xen.
09:40 < geertu> - Handle our kernel test team for testing v4.14.
09:40 < geertu> - Merged the following patch(es):
09:40 < geertu> - arm64: dts: renesas: salvator-common: add dr_mode property for USB2.0
09:40 < geertu> channel 0
09:40 < geertu> Simon:
09:40 < geertu> - Posted, changes requested:
09:40 < geertu> - Gen3 SoC IPMMU DTS patches
09:40 < geertu> - Posted, now under review:
09:40 < geertu> - [PATCH 0/2] iommu/ipmmu-vmsa: r8a779(70|95) support
09:40 < geertu> - Posted, now accepted:
09:40 < geertu> [PATCH] ARM: dts: koelsch: Move cec_clock to root node
09:40 < geertu> [pause to let people catch up]
09:41 < geertu> Any persone I missed?
09:43 < geertu> B) What I plan to do till next time
09:43 < geertu> Geert:
09:43 < geertu> - Finalize genpd for wake-up devices,
09:43 < geertu> - Initial support for Salvator-X with R-Car M3-N?
09:43 < geertu> Marek (U-Boot):
09:43 < geertu> - UBoot: Start converting Gen2 to DM/DT
09:43 < geertu> Morimoto:
09:43 < geertu> - Solve DMAC TCR/TCRB issue.
09:44 < geertu> Niklas:
09:44 < geertu> - Hook up V3M and make sure I can boot it.
09:44 < geertu> - Start to look at 'Add support for more than 32-bits IOVA space'
09:44 < geertu> Shimoda:
09:44 < geertu> - Add usb3.0 phy device node for r8a779[56].dtsi.
09:44 < geertu> Simon:
09:44 < geertu> - Address review of CPUFreq/Z,Z2 Clock patches
09:44 < geertu> - Address review of Gen3 SoC IPMMU DTS patches
09:44 < geertu> - Upport lots of BSP pinctrl patches
09:45 < geertu> My comment here is that several of the patches listed are alrwady upstream ;-)
09:45 < geertu> s/alrwady/already/
09:45 < horms> geertu: ok, I thought I had pruned those. I'll prune again.
09:45 < horms> Unless kaneko-san posts them before I get that far
09:48 < geertu> C) Problems I have currently
09:48 < geertu> Morimoto:
09:48 < geertu> - I still don't understand DMAC TCR/TCRB issue on serial.
09:48 < geertu> I think problem is in rx_timer_fn().
09:48 < geertu> According to Geert, "With your patch, the serial driver doesn't know
09:48 < geertu> about them (residue == 0), and the console doesn't see them." What does
09:48 < geertu> this mean?
09:48 < geertu> BTW, about commit e7327c09def48ccf ("serial: sh-sci: Pause DMA engine and
09:48 < geertu> get DMA status again"), I guess the reason why "transaction completes
09:48 < geertu> _after_ DMA stopped" is that it used TCR instead of TCRB?
09:49 < geertu> Perhaps I wasn't very clear in my initial bug report, but serial console input just doesn't work when SCIF DMA is enabled.
09:50 < morimoto> geertu: thank you for your report, we will check it again.
09:51 < wsa_> gotta go, cya guys!
09:51 -!- wsa_ [~wsa@p54B33A46.dip0.t-ipconnect.de] has quit [Quit: ...]
09:51 < horms> ciao
09:51 < geertu> horms: Goodbye!
09:51 < geertu> Oops, wsa_: Goodbye!
09:52 < geertu> morimoto: Checking the direction again may help.
09:52 < morimoto> Yeah, it seems we can guarantee data if we can check DE bit
09:53 < morimoto> geertu: can you agree ?
09:53 < geertu> morimoto: But DE is not the direction bit?
09:54 < morimoto> Yes. using TCR vs TCRB is checking direction
09:54 < morimoto> and guarantee is checking DE bit
09:54 < geertu> With "guarantee", you mean to be sure the DMA has completed?
09:54 < morimoto> yes
09:55 <@pinchartl> geertu: as far as I understand, the DE bit will be cleared the the hardware when the DMA engine finishes draining its buffers
09:55 < geertu> ok
09:55 < morimoto> pinchartl: yes
09:55 <@pinchartl> I'd like to have a clear explanation as to why SCIF doesn't work with the current patch though
09:56 <@pinchartl> I don't think we should merge anything based on guesswork
09:56 < morimoto> Current SCIF is maybe, DMAC read data from device
09:56 < morimoto> then, TCR was updated
09:56 < morimoto> but, DMAC will buffer it untile transferable
09:57 < morimoto> thus, this timing, TCRB is not updated
09:57 < morimoto> Because of this time gap, TCRB indicate 0x20
09:57 < morimoto> I guess
09:58 < geertu> OK, it's worth a try.
09:58 <@pinchartl> that's the thing, I would feel better with a "I'm sure" than a "I guess" :-)
09:58 < morimoto> :)
09:58 < morimoto> So, geertu: pinchartl: can you agree using direction and DE bit check ?
09:59 < morimoto> using direction = TCR vs TCRB
09:59 < geertu> Yes, it's worth a try. It needs to be tested, though.
10:00 < morimoto> Thanks.
10:00 < morimoto> How about pinchartl ?
10:01 < morimoto> ...
10:01 < morimoto> BTW, on commit e7327c09def48ccfd204025726f11b57a19a9c24, it seems rcar dmac driver doesn't support dmaengine_pause() ?
10:02 < geertu> That's correct, AFAIK.
10:02 <@pinchartl> morimoto: I'm not sure yet, I need to analyze the problem in details. knowing how it works when checking the DE bit would help me understanding
10:03 < morimoto> pinchartl: OK, so I will create patch, and add [RFC]. can you check it ?
10:04 <@pinchartl> morimoto: can you run the patch and include the results ? :-)
10:04 < geertu> morimoto: Please check it doesn't break the serial console before posting ;-)
10:04 < morimoto> geertu: Hehe OK :)
10:04 < morimoto> pinchartl: OK, will try
10:04 < horms> geertu: is "[PATCH 2/3] soc: renesas: Identify R-Car M3-W ES1.1" good to merge? I think so after our discussion with shimida-san on periperi ML.
10:05 < geertu> Case closed 9for now)?
10:05 < morimoto> Sound and SCIF are only user of residue ?
10:05 < geertu> horms: I think it is.
10:05 < horms> thanks, I'll add it the next time I go through my queue
10:05 < geertu> Do you want me to update the patch description with future ES info? Or is that considered too confidential for now?
10:05 < horms> Lets keep it to ourselves
10:06 < geertu> OK, fine for me.
10:06 < geertu> s/9now/(now/
10:06 < horms> I'll just mention that we had some discussion and it seems likely to work for current and future SoCs
10:06 < geertu> If the hardware people change their mind, we need to change the tests anyway
10:06 < horms> About "[PATCH v4 0/3] iommu/ipmmu-vmsa: r8a7796 support V4". I suppose this is a question for dammsan. But should I rebase/repost?
10:06 < horms> geertu: yes, exactly
10:07 < geertu> horms: dammsan said repost in a recent email
10:07 < horms> The important bit is that its unlikely there will be a clash
10:07 < geertu> Indeed.
10:07 < geertu> Any other topics for
10:07 < geertu> Topic 2. Discussion Topics
10:07 < geertu> ?
10:07 < horms> ok. sorry for missing that. I'll do so
10:07 < morimoto> dammsan is here, please wait
10:07 < horms> I will leave very soon, btw
10:08 < dammsan> horms: i think it is fine to wait with the repost
10:08 < dammsan> but feel free to post if it helps your integration work
10:09 < horms> dammsan: what is the motivation for wating. It effects my integration work in the sense that it adds new bindings. and is a dependency for bindings for other SoCs.
10:09 < dammsan> my gut feeling is that it is good to hold off addting code to avoid potential issueeeees
10:10 < horms> ok, perhaps just repost the bindings?
10:10 < dammsan> good idea
10:10 < horms> ok, will do
10:10 < dammsan> together with other ones too if you like
10:10 < dammsan> we have to revisit non-H3 support in the driver anyway
10:10 < horms> I'll repost all the outstanding bindings but not the driver code. Is that what you have in mind?
10:10 < dammsan> sure
10:10 < dammsan> thanks
10:10 < dammsan> sounds ogod
10:11 < horms> One last question, I take it that you intentionaly did not post a fallback binding
10:11 < dammsan> yeah, the IP varies with soc
10:11 < horms> thanks, got it
10:11 < dammsan> thanks
10:12 < horms> I need to go now, sorry for any inconvenience that causes
10:12 < geertu> I think we're finished with core anyway
10:12 < geertu> horms: Bye!
10:12 < horms> perfect
10:12 < horms> bye
10:12 -!- horms [~horms@61.40.109.130] has quit [Quit: Leaving]
10:13 <@pinchartl> one question for core
10:13 <@pinchartl> (and actually for I/O too, I should have asked earlier)
10:13 <@pinchartl> what's the status of V3M support ?
10:15 < geertu> pinchartl: Boots using serial console, NFS root should work
10:15 <@pinchartl> and while waiting for an answer to that question, let's see who's ready for the multimedia meeting
10:15 <@pinchartl> hi jmondi2
10:15 <@pinchartl> hi kbingham[m]
10:15 <@pinchartl> hi dammsan
10:15 [Users #periperi]
10:15 [@pinchartl] [ jmondi2 ] [ Marex ] [ mturquette]
10:15 [ dammsan ] [ kbingham ] [ marex-cloud] [ neg ]
10:15 [ geertu ] [ kbingham[m]] [ morimoto ] [ shimoda ]
10:15 -!- Irssi: #periperi: Total of 12 nicks [1 ops, 0 halfops, 0 voices, 11 normal]
10:15 <@pinchartl> hi morimoto
10:15 < kbingham[m]> I'm here
10:15 < kbingham[m]> Morning
10:15 <@pinchartl> hi ul[tab]
10:15 <@pinchartl> no Ulrich today
10:15 <@pinchartl> hi neg
10:15 < jmondi2> I'm here too!
10:15 < neg> pinchartl: I'm not sure about the status, got a V3M yesterday and plan to try and take it for a first spin
10:16 < kbingham[m]> geertu: . Does i2c work?
10:16 <@pinchartl> geertu: any idea whether I2C is working ? how about PFC, is that still unmerged ?
10:16 < geertu> pinchartl: Sergey is working on upstreaming PFC
10:17 < geertu> Unfortunately he discovered recently he doesn't have the xls files describing pin mappings
10:17 <@pinchartl> -_-'
10:17 <@pinchartl> that's a bit of a blocker
10:18 < geertu> I told him to post the initial version anyway. We typically don't bother reviewing the register definitions, and we can review pin groups
10:19 <@pinchartl> thanks
10:19 <@pinchartl> so let's start with the multimedia meeting
10:19 <@pinchartl> welcome everybody
10:19 <@pinchartl> (I expect Magnus and Morimoto-san to come back soon)
10:19 <@pinchartl> first topic, status update
10:20 < geertu> Let's finish the core meeting: Thanks for joining, and have a nice continued day!
|
