[PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

[Eric Anholt]

Mauro Carvalho Chehab <mchehab at s-opensource.com> writes:

> Em Fri, 27 Jan 2017 13:54:57 -0800
> Eric Anholt <eric at anholt.net> escreveu:
>
>> Here's my first pass at importing the camera driver.  There's a bunch
>> of TODO left to it, most of which is documented, and the rest being
>> standard checkpatch fare.
>> 
>> Unfortunately, when I try modprobing it on my pi3, the USB network
>> device dies, consistently.  I'm not sure what's going on here yet, but
>> I'm going to keep working on some debug of it.  I've unfortunately
>> changed a lot of variables (pi3 vs pi2, upstream vs downstream, vchi's
>> updates while in staging, 4.9 vs 4.4), so I probably won't figure it
>> out today.
>> 
>> Note that the "Update the driver to the current VCHI API" patch will
>> conflict with the outstanding "Add vchi_queue_kernel_message and
>> vchi_queue_user_message" series, but the fix should be pretty obvious
>> when that lands.
>> 
>> I built this against 4.10-rc1, but a merge with staging-next was clean
>> and still built fine.
>
> I'm trying it, building from the linux-next branch of the staging
> tree. No joy.
>
> That's what happens when I modprobe it:
>
> [  991.841549] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
> [  991.842931] vchiq_get_state: g_state.remote == NULL
> [  991.843437] vchiq_get_state: g_state.remote == NULL
> [  991.843940] vchiq_get_state: g_state.remote == NULL
> [  991.844444] vchiq_get_state: g_state.remote == NULL
> [  991.844947] vchiq_get_state: g_state.remote == NULL
> [  991.845451] vchiq_get_state: g_state.remote == NULL
> [  991.845954] vchiq_get_state: g_state.remote == NULL
> [  991.846457] vchiq_get_state: g_state.remote == NULL
> [  991.846961] vchiq_get_state: g_state.remote == NULL
> [  991.847464] vchiq_get_state: g_state.remote == NULL
> [  991.847969] vchiq: vchiq_initialise: videocore not initialized
>
> [  991.847973] mmal_vchiq: Failed to initialise VCHI instance (status=-1)

Yeah, this failure mode sucks.  I'm guessing you don't have a VCHI node
in the DT?  Patch attached.

I haven't followed up on getting the DT documented so that it can be
merged, and it sounds like Michael has some plans for changing how VCHI
and VCHI's consumers get attached to each other so that it's not
DT-based anyway.

From 9488974b836b1fba7d32af34d612151872f9ce0d Mon Sep 17 00:00:00 2001
From: Eric Anholt <eric at anholt.net>
Date: Mon, 3 Oct 2016 11:23:34 -0700
Subject: [PATCH] ARM: bcm2835: Add VCHIQ to the DT.

Signed-off-by: Eric Anholt <eric at anholt.net>
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index caf2707680c1..f5fb5c5aa07a 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -26,6 +26,14 @@
 			firmware = <&firmware>;
 			#power-domain-cells = <1>;
 		};
+
+		vchiq {
+			compatible = "brcm,bcm2835-vchiq";
+			reg = <0x7e00b840 0xf>;
+			interrupts = <0 2>;
+			cache-line-size = <32>;
+			firmware = <&firmware>;
+		};
 	};
 };
 
-- 
2.11.0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170315/13acb00c/attachment.sig>