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
|
h1. Ongoing Multimedia Development
h2. Multi Camera status
(2019/12/12 update)
h3. Current MAX9286 development
* git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git
* Tag: gmsl/v6
* Development Branch: gmsl/dev
h3. Current V4L2 Multiplex series
* https://jmondi.org/cgit/linux
* Branch: v4l2-mux/media-master/v6
h3. MAX9286 driver
I have been improving this driver state over the last couple of weeks to iron out some remaining issues that were left from earlier developments, and related to earlier review comments. I expect to post a v6 version of this imminently
* https://lore.kernel.org/linux-renesas-soc/20191211124459.20508-1-kieran.bingham+renesas@ideasonboard.com/T/#t
There are a couple of 'sub-parts' to this driver:
h3. Eagle-V3M support.
This does not block the posting of the max9286 driver, but has blocked me while I've been working on a fix. The Eagle-V3M powers the cameras from a GPIO connected to the MAX9286 itself.
Describing this as a regulator connected to the GPIO line creates a circular dependency on itself.
I have two lines of investigation to follow on this: Splitting max9286 gpio to an MFD, and creating a new 'bus' type to better define how (/when) the cameras are probed.
To work around this, I have added a gpio-hog to enable the cameras and added a hardcoded 7 second delay into the probe sequence of the driver.
(Not a pretty fix, or upstreamable, but it brings the cameras up...)
h3. Salvator-XS support
This has the well known issue that there are two MAX9286's connected to the same I2C bus. We have a workaround for this, but it is not currently upstreamable.
This is separated out to a distinct patch to facilitate upstreaming the max9286.
h2. Multi Camera plan
(2019/12/12 update)
h3. MAX9286 driver:
I believe I now have a driver for the max9286 which has been greatly cleaned up, and functions on platforms (with a couple of workarounds for external requirements).
Excluding the dependency on the V4L2 Multiplexed stream series, this driver can capture from multiple streams on the RCAR-Vin (without per-stream-format-validation) and could be restricted further to support only a single stream if someone complains about the validation.
I plan to post v6 imminently, and I hope that it is in a state that it could be upstreamed independently of the other topics.
I am already aware of an engineer using/developing on top of this driver at Linaro on a Qualcomm platform.
* Upstream aims:
** Core driver
*** Short term (Hopefully!)
** Eagle-V3M extended requirements
*** Medium term.
** Salvator-X "two-max9286s"
*** Out of tree workaround
h3. RDACM20
The Camera driver needs to be broken down to better support reuse of the individual components, (as expressed by the RDACM21 also using the max9271).
Jacopo plans to work on this, and then later we will look at supporting the RDACM21, making use of the reusable components at that point.
* Upstream Aims
** Medium term.
h3. V4L2 Multiplexed streams
Jacopo has refreshed this series recently, and has had meetings with other core V4L2 developers (I think he met with Sakari in particular) to discuss the direction of this patch series.
It is long and complex, and finding agreement on key topics such as how to correctly filter on DT (data-type, *not device-tree*) tags is difficult.
The complexities of this series has led us to aim to getting the MAX9286 upstream without it so that we can progress, and aim to support the MAX9286 multiple streams correctly along with the ADV748x when the V4L2 Multiplex series progresses.
* Upstream aims
** Long term.
h2. Small Tasks Candidates
When completing a task from this list please mark it as complete and mention your name and the patch series that addresses it.
* Fix MEDIA_ENT_F_VID_IF_BRIDGE documentation
MEDIA_ENT_F_VID_IF_BRIDGE is documented in Documentation/media/uapi/mediactl/media-types.rst as follows.
** Video interface bridge. A video interface bridge entity must have at least one sink pad and at least one source pad. It receives video frames on its sink pad from an input video bus of one type (HDMI, eDP, MIPI CSI-2, ...), and outputs them on its source pad to an output video bus of another type (eDP, MIPI CSI-2, parallel, ...).
** The second and third sentences are incoherent regarding the number of pads. Fix them.
* Fix media_entity_get_fwnode_pad() typo
** In include/media/media-entity.h, s/dose/does/.
* Make i2c_new_secondary_device() return an error pointer
** To be meaningful that requires i2c_new_dummy() to return an error pointer too.
* Fix "warning: Function parameter or member 'foo' not described in 'bar'" warnings when compiling kernel documentation
* Fix the DU ESCR handling (DU channels that have a DPLL don't have ESCR dividers)
* Fix vsp-test failures on H3 ES1.1
** The following tests fail:
*** UDS scaling (vsp-unit-test-0003.sh)
*** CLU/LUT (vsp-unit-test-0010.sh)
*** Runtime H/V flip (vsp-unit-test-0012.sh)
*** SRU scaling (vsp-unit-test-0015.sh)
*** HGT (vsp-unit-test-0023.sh)
* Support MEDIA_BUS_FMT_UYVY8_1X16 in VIN and MEDIA_BUS_FMT_YUYV8_1X16 in CSI-2
h2. Completed tasks
* Fix the VSPD memory regions in r8a7795.dtsi and r8a7796.dtsi
* The memory regions should include the RPF OSD-CLUT tables.
** [PATCH v3 3/5] arm64: dts: renesas: r8a7795-es1: Fix register mappings on VSPs
** [PATCH v3 4/5] arm64: dts: renesas: r8a7795: Fix register mappings on VSPs
** [PATCH v3 5/5] arm64: dts: renesas: r8a7796: Fix register mappings on VSPs
|
