wiki: update Ongoing Multimedia Development

For Multi Camera which is asked from BSP team.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

2 files changed, 80 insertions, 0 deletions

diff --git a/scripts/css b/scripts/css
index a5f5e04..41b2554 100644
--- a/scripts/css
+++ b/scripts/css
@@ -32,3 +32,7 @@ pre {
   padding: 10px 10px;
   border-radius: 10px;
 }
+
+strong {
+   background: linear-gradient(transparent 30%, #bbbb00);
+}
diff --git a/wiki/Ongoing_Multimedia_Development.wiki b/wiki/Ongoing_Multimedia_Development.wiki
index e40496b..052f1a4 100644
--- a/wiki/Ongoing_Multimedia_Development.wiki
+++ b/wiki/Ongoing_Multimedia_Development.wiki
@@ -1,5 +1,81 @@
 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.