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
|
Core-chat-meeting-2017-06-06
10:02 < geertu> Welcome to today's Core Group Chat!
10:03 < geertu> Agenda:
10:03 < geertu> 1. Status updates
10:03 < geertu> 2. Discussion topics
10:03 < geertu> Topic 1. Status updates
10:03 < geertu> A) What have I done since last time
10:03 < geertu> B) What I plan to do till next time
10:03 < geertu> C) Problems I have currently
10:04 < geertu> (tampered with) sort -R said Niklas is first
10:04 < neg> A) No core task ATM
10:04 < neg> B) No plane all time will go to multimeda work next two weeks.
10:04 < neg> C) None
10:04 < neg> EOT
10:05 < neg> s/plane/plan/
10:05 < geertu> Thank you, Niklas
10:05 < geertu> Next is Marek
10:05 < Marex> A) ULCB U-Boot support patch (tested on dammsans board remotely by booting u-boot from u-boot) B) Submit the ULCB U-Boot patch mainline C) No ULCB available, need to buy one to test flashing the U-Boot instead of booting U-Boot from U-Boot
10:06 < Marex> EOT
10:07 < geertu> I think C is something to discuss with Öpensöurce AB
10:07 < Marex> geertu: correct, already work in progress
10:07 < geertu> Thank you Marek.
10:07 < geertu> Next is Morimoto-san
10:07 < morimoto> A) = B) = C) = NULL, sir
10:08 < geertu> Thank you Morimoto-san!
10:08 < geertu> Next is Mangnus, who is excused.
10:08 < geertu> Next is Laurent, who is on holidays
10:08 < geertu> Next is Jacopo
10:08 < jmondi> A) Add GR-Peach DTS file
10:09 < jmondi> - still discussing RZ pinctrl, found a possible way forward
10:09 < jmondi> B) RZ pinctrl
10:09 < jmondi> C) None
10:09 < jmondi> -- eof --
10:09 < geertu> s@RZ@RZ/A1@
10:10 < jmondi> geertu: yes, RZ/A1
10:10 < geertu> Thank you Jacopo!
10:10 < jmondi> some other RZ are not really RZ :p
10:10 < geertu> Next is Geert
10:10 < geertu> A) What have I done since last time
10:11 < geertu> - Tested H3ULCB with H3 ES2.0
10:11 < geertu> - Looked into D3 CPG/MSSR
10:11 < geertu> - Made inventory of code under arch/arm/mach-shmobile that still needs DT
10:11 < geertu> conversion, and converted that into a list of tasks for
10:11 < geertu> peripelist/core/todo
10:11 < geertu> - Started looking into suspend/resume for CPG/MSSR and PFC
10:11 < geertu> - Issue is complicated because hardware state is not just lost, but
10:11 < geertu> also different from hardware state on kernel entry during normal
10:11 < geertu> boot.
10:11 < geertu> E.g. on normal boot, U-Boot disables several module clocks.
10:11 < geertu> B) What I plan to do till next time
10:11 < geertu> - Test Salvator XS (when it has arrived)
10:11 < geertu> - Suspend/resume for CPG/MSSR and PFC
10:11 < geertu> - Mark periupport priority < H commits that are in linux-next
10:11 < geertu> C) Problems I have currently
10:11 < geertu> - None
10:11 < geertu> EOT
10:12 < geertu> Next is Simon, who is excused
10:12 < geertu> Next is Shimoda-san
10:12 < shimoda> A) study R-Car D3 CPG spec. and forwarded it to Geert-san :)
10:12 < shimoda> B) investigate R-Car D3 CPG things (especially, I should reply Geert-san's email)
10:12 < shimoda> C) about pause feature in rcar-dmac
10:12 < shimoda> -- EOT ---
10:13 < geertu> Thank you Shimoda-san!
10:13 < geertu> Which brings us to
10:13 < geertu> Topic 2. Discussion topics
10:13 < geertu> Shimoda-san?
10:13 < shimoda> yes
10:14 < geertu> Please explain your problem
10:16 < shimoda> problem is that sh-sci and rcar-dmac implementation is unbalance. I'm not sure it is OK or not
10:17 < geertu> You mean sh-sci calls dmaengine_pause(), while rcar-dmac doesn't implement it?
10:17 < shimoda> sh-sci driver calls dmaengine_pause() but rcar-dmac doesn't have .device_pause() for now
10:18 < shimoda> geertu: yes
10:18 < shimoda> for now, i don't encounter any problem, but this implementation is storange to me
10:18 < shimoda> s/storange/strange/
10:19 < shimoda> since we don't have any issue, we can use them as-is though :)
10:20 < geertu> The sh-sci driver has a workaround for the absence of .pause(), cfr. the commit that introduced the call (e7327c09def48ccfd204025726f11b57a19a9c24)
10:21 < geertu> But I agree the DMA implementation of sh-sci is far from perfect
10:22 < geertu> So Magnus suggested to make a test case if .device_pause() is really needed or not?
10:22 < shimoda> geertu: yes
10:24 < geertu> Due to the workaround, I think it's not needed now.
10:26 < geertu> IIRC, dmaengine_pause() can be called in interrupt context, while dmaengine_terminate_all() cannot (but it's possible we still violate that)
10:26 < shimoda> geertu: "it's" means .device_pause?
10:26 < geertu> In the mean time, dmaengine_terminate_all() has been deprecated, in gavor of dmaengine_terminate_sync() or dmaengine_terminate_async()
10:27 < geertu> Yes, I meant .device_pause() is not needed due to the workaround
10:27 < geertu> s/gavor/favor/
10:27 < shimoda> oh, i don't know dmaengine_terminate_all has been deprecated
10:28 < geertu> dmaengine_terminate_async() can be called from interrupt-context, dmaengine_terminate_sync() cannot
10:28 < shimoda> i see
10:28 < geertu> Perhaps Niklas has a better understanding of the modern DMA API?
10:31 < shimoda> about sh-sci point of view, keep the dmaengine_pause calling is better? or should we revert it?
10:31 < neg> not much about the pause implementation I only studied the terminate case
10:33 < geertu> shimoda: The commit that added the pause also added the workaround, so it's better to not revert it
10:35 < neg> but yes terminate_async() is the new API, and my understanding is that you should call device_synchronize() after that at some point to make sure it did terminate
10:35 < shimoda> geertu: about workaround patch, there are the followings?
10:36 < shimoda> 3b96304 serial: sh-sci: Do not terminate DMA engine when race condition occurs
10:36 < shimoda> 1d3db60 serial: sh-sci: Call dma_async_issue_pending when transaction completes
10:36 < shimoda> 371cfed serial: sh-sci: Redirect port interrupts to CPU _only_ when DMA stops
10:36 < geertu> https://patchwork.kernel.org/patch/7289991/ was an attempt to add pause support to rcar-dmac
10:37 < geertu> shimoda: Those are fixes for different issues
10:38 < shimoda> geertu: thank you! but the rcar-dmac patch was rejected in upstream, i think
10:38 < geertu> Indeed, Laurent didn't like it
10:41 < shimoda> i got it. i will check about Laurent-san's opinion in the patchwork later
10:41 < geertu> I'll also add a task to look into pause again
10:43 < shimoda> geertu: thank you for adding it
10:45 < shimoda> so my concern point is cleared, thank you!
10:45 < geertu> good to hear that
10:45 < geertu> Do we have anything else to discuss?
10:46 * Marex might've found VC6 devkit to buy
10:46 < shimoda> nothing from me
10:48 < Marex> geertu: shall I grab the VC6 kit ?
10:48 < geertu> Marex: I suppose you'll receive a Salvator-XS anytime soon?
10:48 < Marex> geertu: I will ? :-)
10:49 < Marex> geertu: anyway, the VC6 kit has RSMA connectors for each output to it's easy to measure the frequency
10:49 < geertu> morimoto: Has it been shipped to Öpensöurce AB yet?
10:49 < Marex> geertu: $186 ... hm
10:50 < geertu> Marex: You forgot to write the driver in Tokyo? ;-)
10:51 < Marex> geertu: I didn't have hardware access there :'-(
10:52 < geertu> Marex: too bad
10:52 < Marex> geertu: still, I feel like grabbing the kit would help also because the i2c is accessible and I can operate it with the clock commander (IDT tool for programming the chip) and I can snoop on the i2c bus to figure out the gaps in the datasheet
10:52 < geertu> Marex: Please check with Magnus
10:53 < Marex> geertu: OK
10:53 < geertu> Then I think we're finished
10:54 < geertu> Thanks for joining, and have a nice continued day
|
