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
|
h1. +MiniPeriCon 2016-07+
| Date | 2016/07/11 |
| Place | Tokyo |
|/8. Member | Geert |
| Laurent |
| Morimoto |
| Niklas |
| Simon |
| Wolfram |
| Shimoda |
| Khiem |
!2016-07-miniperi/linuxcon2016.png! !2016-07-miniperi/wsa2016.png!
!2016-07-miniperi/wolf.png! !2016-07-miniperi/lcj.png!
h1. +I/O meeting+
h2. Chat meetings
* members send todo updates by mail before meeting starts
* short focussed meetings. everyone answers
** what have I worked on since last time
** what will I work on until next time
** I have the following problems (or not)
* once every two weeks
h2. Additional tasks for 8/M
* We just wait
h2. Base tasks
* Wolfram: ask for reports
* Niklas is okay doing base tasks occasionally
h2. Additional tasks
* priorities of tasks need to be clear for developers to decide
* especially across groups
h3. batch 1
* SDHI: fix SDR104 issues and enable on Gen3 - Simon (5d)
* I2C & SDHI maintenance - Wolfram (5d)
h3. batch 2
* SDR integration for all boards and/or PFC SDHI voltage for all our SoCs - Simon (5d)
* SPI: implement slave prototype - Geert (5d)
* SDHI with UHS - Wolfram (5d)
h3. todo
* Ethernet: 64bit memory support for Gen3 - ? (5d)
* HSCIF HW timeout - Geert (10d?)
* 8bit eMMC supprt for SDHI
* HS200/400 support for eMMC after that
h1. "Core meeting":../../wiki/2016-07-miniperi/2016-07-11_MiniPeriPeriCon_Handouts.pdf
h2. Additional task
h3. for 8/M
* Geert : R-Car H3 MSOIF Parent Clock Control Prototype
* Simon : R-Car M3-W Suspend-to-RAM Prototype
* Ulrich : R-Car M3-W SYS-DMAC Integration
* Laurent/Kieran : R-Car H3 Pin Function Controller Drive Strength of Non-I/O pins Upstream Development (TBC)
h3. for 9/M
* Geert : Renesas-drivers Git Repository Maintenance
* Simon : R-Car M3-W Kexec Prototype
h3. noplan/noschedule
* M3-W 64bit memory support
* Prototype for DT fixup (first RFC sent)
* M3-W more suspend-to-ram
* M3-W PFC enhancements
** IPSR17 is strange
** http://www.spinics.net/lists/linux-renesas-soc/msg05211.html
* Migrate to CPG/MSSR
* Start adding dmas pointing to SYS-DMAC2 (needs secure firmware 2.8.0)
h2. Dirk's topic
h3. ESx.y
* API to access Product Register (PRR), used by drivers
* Fixup DT (change compatible value)
** May need both? Lattter is needed to e.g. change number of device instances
h3. Sharing clock definitions
h3. Sharing dtsi
* Cfr. iMX6
* SoC-specific: compatible value, core clocks, module clock (not CPG/MSSR), power area (although identical numbers per family)
* Plain numbers in DT: IRQs, DMAs, module clocks
h1. +MultiMedia meeting+
h2. OF graph for ALSA (Morimoto-san)
ALSA will use OF graph base DT.
http://thread.gmane.org/gmane.linux.kernel/2252365/focus=156164
which is better from HDMI video point of view ?
This is good for HDMI vidoe / sound
<pre>
port@0 {
type = "video";
endpoint {
remote-endpoint = <&xxx>;
};
};
port@1 {
type = "sound";
endpoint {
remote-endpoint = <&xxx>;
};
};
</pre>
This is good for multi-connection
<pre>
port {
type = "sound";
endpoint {
remote-endpoint = <&xxx>;
};
endpoint {
remote-endpoint = <&xxx>;
};
};
</pre>
h2. V4L2 support for subdevices with more than one output pipeline (Niklas)
HDMI input (and output) is of no interest to the BSP team at the moment. We thus don't need to upstream the ADV7482 driver, and can develop a simplified driver for testing purpose that hardcodes the data path. CVBS input would be simpler than the HDMI input, but on the other hand HDMI input is useful to use for HDMI loopback testing. Unless implementing support for the HDMI path (including EDID programming) turns out to be significantly more complex than currently thought, let's do that.
No extension to V4L2 to make several operations pad-aware (s_stream, *std, ...) is thus needed as we will hardcode one path in the ADV7482 driver.
In Gen3 VIN instances share UDS and CSI selectors, as well as possibly an ISP on V3H. The hardware is reaching the level of complexity that requires exposing the MC API to userspace. Link configuration will then be used to control UDS sharing.
For CSI routing, the hardware is peculiar and complex, and link configuration might not be a good match. Exposing the CSI selectors as entities with an API (either at the V4L2 or MC level) to configure internal routing in the entity
(identical or similar to the set routing ioctl that I proposed) is probably a better solution. Whether that API should be implemented as a V4L2 or an MC ioctl is an open question, as the feature isn't V4L2-specific. Whether that
API should allow enumerating the supported routing options is also an open question, the hardware is so peculiar that a device-specific userspace will likely be needed anyway. Another problem that needs to be solved is how to
handle locking routes, as we shouldn't allow messing up an active stream, and configuring unrelated links could impact other routes due to the way the hardware is implemented.
h2. Second batch of additional tasks for Q3 (Laurent)
* Niklas: Lots of work on VIN + MC. Base contract would cover upstreaming, including getting API extensions accepted. Additional tasks can cover preparation for upstreaming, and ADV7482 work (including EDID programming).
* Ulrich, Laurent, Kieran: Let's discuss this again after RenesasCon where the BSP team will likely request additional features.
h2. What are we doing right or wrong, and how can we improve (Laurent)
A largely unexplored area for improvements is automated testing, we should invest more in regression tests that could be run either in board farms or by developers as part of the patch submission process.
h2. Long-term roadmap (Laurent)
The industry is moving to V4L2 for video codecs, with Android being influenced by ChromeOS in that regard. Several SoC vendors are posting open-source kernel drivers for codecs, but Renesas is lagging in that area. There is currently no plan for Renesas to change this. Codec support is provided to customers through a GStreamer element, the underlying API isn't relevant and no request for V4L2 support has been received so far. However, if we could provide convincing business reasons to move to V4L2, the position could be reconsidered. One possible benefit would be to reuse generic GStreamer video codec code instead of having to maintain a separate GStreamer element.
h2. UDS sharing for VIN devices on Gen3.
Time to add MC support to rcar-vin and/or other ides to reduce resource sharing complexity.
h2. Possible new task, Gen3 datasheet (rev0.52e) adds one new possible video input source ISP (Image Signal Processor) for R-CarV3M.
The block is not documented other then with a list of features and a block diagram.
|
