The TODO list has port the camera to ARM64. That's done. The list also mentions the error where the camera module won't load if the camera isn't connected yet. vchiq already has a mechanism to deal with calling back into consumer when vchiq connects, so instead of adding more code hook into that mechanism. That completes another TODO item. Signed-off-by: Michael Zoran <mzoran@xxxxxxxxxxxx> --- drivers/staging/vc04_services/bcm2835-camera/TODO | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/drivers/staging/vc04_services/bcm2835-camera/TODO b/drivers/staging/vc04_services/bcm2835-camera/TODO index 61a509992b9a..713291bf0fdf 100644 --- a/drivers/staging/vc04_services/bcm2835-camera/TODO +++ b/drivers/staging/vc04_services/bcm2835-camera/TODO @@ -16,23 +16,7 @@ hardware can do. If we exposed the native padding requirements through the V4L2 "multiplanar" formats, the firmware would have one less copy it needed to do. -3) Port to ARM64 - -The bulk_receive() does some manual cache flushing that are 32-bit ARM -only, which we should convert to proper cross-platform APIs. - -4) Convert to be a platform driver. - -Right now when the module probes, it tries to initialize VCHI and -errors out if it wasn't ready yet. If bcm2835-v4l2 was built in, then -VCHI generally isn't ready because it depends on both the firmware and -mailbox drivers having already loaded. - -We should have VCHI create a platform device once it's initialized, -and have this driver bind to it, so that we automatically load the -v4l2 module after VCHI loads. - -5) Drop the gstreamer workaround. +3) Drop the gstreamer workaround. This was a temporary workaround for a bug that was fixed mid-2014, and we should remove it before stabilizing the driver. -- 2.11.0 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
